Qwen3.8 + Spring AI：开源大模型如何接入OA企业办公，业务系统与智能体各负责什么
🌐 产品手册：https://ruoyioffice.com/
👇 文章底部提供智能体与业务系统两种体验入口 👇
💬 ：17156169080（获取 AgentOS 产品咨询）
员工问“我现在有哪些待办”，系统需要知道他是谁、能看哪些流程；员工说“部署手册进度改成90%”，准备保存的周报必须同步更新；员工上传发票，还需要确定公司、账套、费用类型和收款信息。
这三件事都需要模型理解自然语言，也都需要企业系统提供真实依据。我们的实践是把本地开源模型接入已有的 RuoYi Office 业务平台，由 AgentOS 把员工身份、业务工具和人工确认串起来。
本文展示已落地的接入与确认前实测，属于A级观察。文中 Qwen3.8 指本轮使用的第三方 Coder390 Q3 权重命名，具体来源与运行条件见下一篇；不能据此推断同名其他模型的效果。AgentOS 是支持私有部署的商业加购扩展，所接模型与扩展产品的许可分别确认。
本地模型底座：实际部署了什么
本轮本地推理服务采用llama.cpp b11429与Windows CUDA12.4运行包，加载27B的Coder390 Q3 GGUF权重。模型文件为17.30GB（十进制），约16.12GiB；这是磁盘体积，不能直接当作显存需求。机器使用64GB内存、驱动报告22528MiB显存的改配2080Ti，普通11GB版本不能照搬。
部署分为三个可检查的阶段：下载固定版本运行包和权重、按SHA256核验文件；启动独立llama-server并等待health就绪；把兼容API接到AgentOS，使用普通员工验证工具任务。模型权重、运行环境、日志与证据分别存放，密钥和模型文件留在代码仓外。
模型以qwen3.8-27b-local作为API别名，在本机18084提供服务。本轮固定8K上下文、q8_0 KV、并发1、4个CPU线程，关闭思考和MTP。员工看到的对话框由业务应用提供，实际文本生成和工具选择发生在这台本地模型机器上。
系统架构示意。模型通过AgentOS获得授权工具描述与结果，没有直接访问业务数据库的通道；图中的能力仍需对应接口和权限验收。
一次对话怎样真正走到本地Qwen
AgentOS将员工输入、必要历史和授权工具定义组成模型请求。Qwen可以返回文字，也可以返回tool_calls；应用执行对应工具，再把真实结果回填给模型。员工提出更正时，新一轮输入会再次进入本地模型，不能只靠上一轮文字保持业务状态。
这是工具往返关系示意。一个员工轮次可能包含多次模型请求，图中轮次不作为固定调用次数。写操作本轮停在确认卡。
因此读者可以沿着三个现象判断本地模型是否参与应用：实际模型进程加载哪份GGUF、Spring AI请求是否指向该兼容服务、返回的工具选择及后续文字是否有对应运行记录。模型页自测一句“ok”只是接入检查，周报更正和报销补问提供更接近办公任务的体验证据。
历史31题Windows Q3裸API评测，生成速度中位数为24.27 tokens/s，条件为温度0.1、seed42、输出上限512和单请求。这不等于员工任务速度：周报还涉及业务查询、模型多次往返及确认准备。部署完成后，应先固定请求配置，再从员工视角记录等待、补问与结果一致性。
一、从员工工作台出发，定义企业应用的输入
员工进入工作台后，左下角展示“智能体验证员工”和所属公司、部门。业务身份沿用平台账号，管理员与普通员工进入的空间和可用能力存在区别。
截图为本地专用测试员工登录后的真实页面。工作台本身不证明任何模型任务已经成功。
“我的待办”中的“我”，必须由平台认证来确定。公司、员工和部门信息也应来自系统上下文，不能交给模型根据聊天内容猜测。
这决定了企业应用的第一项前提：已有可用的账号、任职、权限和业务接口。模型私有部署解决了推理服务的部署位置，接下来还要逐项确认员工能够访问的数据与工具。
结论：企业模型应用需要同时接入自然语言输入与可信业务身份；员工、公司、部门和数据范围应由平台认证与业务接口确定。
二、三者分别提供什么能力
开源模型：理解意图、整理内容、选择工具
本轮模型通过 llama.cpp 提供兼容 API。员工的口述事项可以被整理成周报，缺失信息可以通过对话补充，模型还能提出结构化工具调用。
工具选择仍会出错。本轮 Q3 的31题通用测试通过26题，14项受控测试通过14项，但4项无关工具抑制测试均失败。样本、测试方式和任务复杂度不同，不能用一个合计成绩代表企业可用性。
AgentOS：把表达接到受控的业务能力
AgentOS 使用独立前端、后端进程、数据库与 Redis 边界。它组织对话、提供授权能力、记录工具步骤，并在准备业务写入时展示人工确认卡。调用平台业务接口时透传当前员工 Token，模型服务密钥留在后端。
例如周报实测中，页面可以展开工作汇报、已办审批、出差和办事进度等查询。记录中既有成功返回，也保留了一次日期范围参数转换失败及之后的查询结果。
来自周报会话339的首轮历史记录。失败步骤没有从素材中删除；后续展示的卡片属于同一会话。
业务系统：保留规则、主数据与最终结果
工作汇报的字段定义、账套与费用类型、员工归属和财务规则，仍由业务系统维护。模型提出的参数需要经过应用代码与业务接口校验。
这种组合的价值在于复用已有企业系统：员工能够通过对话表达目标，系统仍能沿用已有业务约束。新增业务场景是否可以接入，需检查接口、权限和确认逻辑，属于具体配置或二开工作，不能把所有模块都写成已经验证。
本地部署还给调优提供了明确边界：模型是否连续提出重复工具调用，应检查原始模型返回；字段无法完整识别，应检查OCR与解析；员工无法进入工作台，应检查认证链路。后两篇的业务界面都使用同一组本地Q3配置，调优与验收依据见第二篇。
结论：开源模型承担理解和生成，AgentOS连接身份、工具与确认，业务系统维护业务规则和结果；三者的责任边界应在接口与运行记录中体现。
三、用一次事项更正观察实际协作
员工最初提供“部署手册完成80%”，随后更正为90%。在本轮 Q3 员工会话339中，前两轮完成整理和更正，第三轮才产生真实确认记录38，对应运行441。
这是历史实测卡片的重新截图，卡片有效期已过。未点击“确认写入”，没有创建OA周报或发起审批。
判定这一轮成功，需要同时核对更正后的文字、准备保存的工具参数和后端确认记录。模型说“已经准备好了”只是其中一种观察，不能代替真实 pending 记录。
这里也可以看出产品边界：确认卡是一份供员工检查的业务操作预览。后续真实保存、重复确认、事务与审批，要另做验收。本轮不能用确认卡成功替代这些结果。
结论：真实确认卡必须能关联工具参数和后端确认记录；模型回复、业务操作预览与实际写入结果需要分别验证。
四、企业接入前先检查这五件事
- 业务基础
：账号、员工档案、公司部门和目标业务接口可用。 - 身份与权限
：使用普通员工验证数据范围，不能只用管理员演示。 - 模型链路
：检查实际权重、运行参数和工具请求，保留失败样例。 - 确认与记录
：能追溯输入、工具参数、结果和确认记录。 - 分阶段验收
：区分部署成功、确认前任务成功与生产业务可用。
当前OCR完整字段识别为84/100，低于95%门禁；整机长期稳定性、多人并发和真实确认后的业务流程尚未验收。这些限制应影响上线范围，也应出现在实施清单里。
五、常见问题
1. 企业系统已经有AI聊天入口，还需要智能体吗？
取决于目标。如果需要读取员工业务数据、准备操作和追溯过程，就要检查入口是否已经具备身份、授权工具、确认与记录能力。
2. 开源模型部署在本地，业务权限就安全了吗？
部署位置与业务权限需要分别验证。工具集合、员工Token、接口权限和数据范围仍由应用及平台控制。
3. 这套方案能接入其他开源模型吗？
兼容接口提供接入基础，但具体模型的工具调用、多轮更正与资源要求仍需复测，不能直接沿用Q3成绩。
4. AgentOS是否开源？
AgentOS是商业加购扩展，支持私有部署。本文讨论接入开源模型，不能将两者的产品属性混同。
六、把组合优势落到可检查的业务步骤
企业应用的差异可以从具体步骤看出来：员工身份是否可信，工具是否真实调用，更正是否进入参数，确认是否有记录。已有业务系统、智能体编排和本地模型的组合，为这些步骤提供了落地基础。
下一篇沿着部署链路说明如何配置与验证；后两篇分别展开周报和报销。你准备让开源模型接入的第一个企业任务是什么？
如果这篇对你有用，点个「在看」或收藏。
🤖 在线体验·智能体：https://ruoyioffice.com/ai/work
🏢 在线体验·业务系统：https://ruoyioffice.com/web/
📘 产品手册：https://ruoyioffice.com/
💬 微信：17156169080（备注「AgentOS」）
可以直接打开智能体，也可以先进入业务系统，再通过右下角“小擎”使用嵌入式助手。