先说个背景。半年前我在某公司做内部AI落地跑在群里的模型已经能回答不少业务问题Chat界面做得漂漂亮亮业务方问得最多的一句话却是这东西除了会聊天到底能帮我们干什么我复盘了一下发现问题出在定位上——大家都把大模型当成了更聪明的对话框没人把它当成能干活的同事。后来我把GPT-6从一个只会接话的模型改造成一个会读文档、会查系统、会跑流程、会在办完事后给结果的企业工作伙伴并且把核心框架整理后放到了公开代码仓库。这篇博文不聊参数和论文就聊聊我踩过的坑、拆过的架构以及这套方案开源出来之后别人怎么复现。1. 聊得好不等于干得动企业AI凭什么从聊天机器人升级为工作伙伴我见过太多企业内部AI项目验收标准居然是模型能不能把员工手册倒背如流。这种项目上线以后基本吃灰因为员工查制度直接搜文档更快没必要绕一圈去对话框里等流式输出。1.1 企业聊天机器人的三个看起来能用、实际上鸡肋的现状第一个现状是只会查不会办。你问它上周的销售数据怎么样它能给你一段摘要但你说帮我把上周销量下滑的客户名单整理成邮件草稿发给对应的销售负责人它就傻眼了。因为后者不是生成文本而是检索数据→分析原因→匹配负责人→生成邮件→按规则发送的一连串动作传统聊天机器人根本没有执行通道。第二个现状是答非所问的锅全让模型背。有一次业务方投诉模型乱说话我查了日志才发现问题根本不在模型而是上层的检索链路把两份同名合同搞混了模型拿到的是错误上下文。这说明光会聊天根本不够周边系统的数据质量、权限边界、溯源能力决定了一个AI工具能不能真正被信任。第三个现状是没有记忆、没有状态。员工和AI聊了半小时最后说按刚才定的方案帮我发起采购申请它完全想不起来刚才定的方案是什么。不是模型不够聪明是我们压根没给它设计记忆系统。工作中真正让人省心的助手至少要记得上一轮说过什么、当前任务进行到哪一步。1.2 我定下的边界工作伙伴必须做到三件事所以我在立项时给企业工作伙伴定了三条硬标准不到位就不算成功任务能闭环从接收一句话指令到工具调用、流程执行、结果反馈全程不需要人工二次拆分。权限可管控AI能读什么、能写什么、能发给谁全部走企业既有权限体系不搞超能力。过程可追溯每一步调用了什么工具、依据了哪份数据、为什么做出这个决定都能拉出审计日志。这三条标准后来成了开源框架的核心设计准则。GPT-6本身的对话能力只是底座真正让聊天变成干活的是一套围绕任务生命周期搭建的调度系统。2. 工作伙伴的第一性问题从对话转为任务闭环的架构设计很多做AI应用的同学一上来就调模型API把提示词写出一朵花结果一接真实业务就崩。问题在于他们把对话当成了系统的全部其实对话只是入口任务生命周期管理才是企业级AI应用的灵魂。2.1 一层模型、一层路由我把系统拆成了四层我最终采用的架构简化以后是四层结构用户请求IM/网页/API ↓ 【会话层】处理多轮上下文识别用户意图管理任务ID ↓ 【调度层】把意图翻译成任务清单分配执行顺序维护状态机 ↓ 【工具层】封装内部系统APICRM/ERP/邮件/文档库/审批流 ↓ 【模型层】GPT-6负责生成、判断、总结但决策权被路由约束很多团队会把模型放在最上面什么都让模型说了算。我反过来了让调度层成为真正的大脑模型反而退化成生成器和判断器。为什么因为模型再强也会有幻觉但一套写死的状态机不会——计划该分几步、哪步能并发、哪步必须等前置结果这些都应该是确定性逻辑而不是让模型自由发挥。2.2 任务状态机的设计为什么需要计划-执行-校验-收尾我在系统里给每个任务定义了一个状态机pending → planning → executing → verifying → done/failed。这个设计参考了工作流引擎的思路但做了一层关键改造——planning和verifying这两步交给GPT-6executing交给工具层收尾再交给模型做总结。举个例子用户说帮我把上季度毛利低于20%的产品线整理成报告抄送给负责人。调度层先让GPT-6做planning产出子任务1. 从BI系统取数2. 按产品线聚合计算毛利3. 筛选低于20%的条目4. 生成Markdown报告5. 查询负责人邮箱6. 发送邮件。每个子任务进入executing后由具体工具执行执行完的结果再回给GPT-6做verifying——数据里有没有明显异常汇总数字和明细是否相符——通过后才继续下一步。这套设计最大的好处是模型只负责它擅长的部分拆解、判断、总结不负责它不擅长的事精确计算、执行API调用。我在实测中发现如果让GPT-6直接一步步调用工具它会在第三步左右开始犯迷糊忘了前面拿到的数据字段而用状态机兜底以后任务成功率直接从62%提到了91%。2.3 工具层如何长在企业系统上工具层是这套架构里最容易低估的部分。我最初只接了邮件和文档库两个接口后来业务方提了一堆需求——查ERP订单状态、调CRM客户信息、发起OA审批、更新共享表格。每一个系统都得单独写适配器适配器要处理鉴权、字段映射、超时、错误码。这里有一个关键经验永远不要直接让模型拿真实的内部API地址。我在工具层外面又包了一层符号注册表也就是给每个工具起一个语义化名字比如query_customer_contracts、send_email_to_owner工具参数用JSON Schema描述模型只学习这批符号真实接口地址和鉴权密钥放在工具适配器里。这样做一方面安全另一方面也方便换后端系统而不动模型逻辑。3. 意图拆解、工具调用与记忆系统三个决定成败的能力拆解如果说架构是骨架那这三个能力就是肌肉。任何一个做得不到位工作伙伴都会退化成聊天机器人。3.1 意图拆解不是关键词匹配而是决策树模型兜底刚开始做意图识别我和很多人一样让模型直接输出一个意图标签比如查数据发邮件审批准确率惨不忍睹——用户表达太随意了这个单子帮我催一下到底是催审批还是催付款后来我改成规则优先、模型兜底的决策树方案。具体的做法是先写一批正则规则覆盖高频确定性场景比如出现打印就一定走打印工具剩下的模糊表达统一交给GPT-6让它输出一个结构化的意图包{ intent: approval_reminder, target_object: PO-2024-118, action: escalate, channel: email, priority: high }调度层拿到这个结构化包就知道该调哪个工具链。我自己的体会是模型负责理解自然语言系统负责理解业务动作各管一摊整体准确率才能稳定在95%以上。3.2 工具调用的正确姿势固定Schema自动重试降级策略工具调用这一块网上教程很少讲清楚。很多人拿着Function Calling的示例就往上堆却忽略了企业环境的三个残酷现实接口不稳定、数据格式脏、权限随时会变。我的做法可以复现每个工具定义严格的JSON Schema参数类型、必填项、取值范围全部写死。模型生成参数后先做一次schema校验不合格就让GPT-6重新生成最多重试2次。同一个任务尽量走幂等的只读接口比如查合同状态只读不写需要写操作时单独走审批流防止模型误操作。工具调用设置超时50秒失败后自动重试1次再失败就降级为生成待人工处理工单并把失败原因记录到审计日志。这里特别提醒千万不要让模型在一条回复里连续调用五六个工具。GPT-6实测在连续工具调用场景下会走神漏参数、记错返回值的情况并不少见。我最终的做法是一次只执行一个工具执行结果回到调度层再让模型决定下一步。虽然多了几次往返但稳定性提升非常明显。3.3 长期记忆会话记忆之外还得有任务记忆记忆系统是大家最爱聊、也最容易做坏的部分。我见过不少方案把全量聊天记录塞进上下文结果上下文爆了模型开始胡说。我把记忆拆成三份工作记忆当前任务的中间变量比如取数已完成报价单IDXC123任务结束即清除。项目记忆跨会话的项目状态比如XX客户合同的续约节点是下周五存在向量库里需要时召回。偏好记忆用户明确表达的偏好比如周报不要包含技术细节单独存JSON。偏好记忆一定不要让模型自动抽取否则会存进一堆幻觉。我的做法是在结束语里提供要不要记住这个偏好的确认按钮用户点确认才写入。这套设计被不少人吐槽不够智能但它的好处是记忆可信——我们经不起模型自己编记忆然后又一本正经地用来回答。4. 实测中的翻车现场工具越权、任务中断与记忆混淆的排查全记录任何系统不经过真实环境毒打都不算数。我把工作伙伴部署到某业务部门试运行一个月翻车翻得很有教育意义。4.1 现场一合同风险扫描越权读取了不该看的文档上线第二周风控部门反馈AI在扫描合同风险时读取了一份不在授权范围内的供应商报价单。我第一时间查了日志定位到根因——工具适配器用了服务账号去调文档库API这个服务账号权限太大能读到所有文档而模型本身并不知道边界。排查链路是这样的先看审计日志发现违规读取动作再看是哪个工具触发的确认是get_document_content再看传给工具的document_id是哪来的结果发现是上游检索系统返回的最后查检索系统为什么返回这份文档结论是索引里没有做权限裁剪。修复方案有两个层面一是工具层强制加权限校验每次读取前先比对当前任务发起人的ACL二是检索层做权限过滤让模型根本看不到无权限的文档。两边都改完后同类问题再没出现过。这个坑的教训是AI应用不能假设模型知道权限边界权限必须写在系统里且越早越好。4.2 现场二批量发票识别跑到一半任务直接挂起另一个问题是批量任务的中断恢复。用户让AI识别100张发票并填入报销单跑到第47张时OCR服务超时整个任务回滚前46张白干。这种体验放聊天机器人时代无所谓重说一遍就行但放在工作伙伴身上用户会直接骂人。我花了一个周搞定断点续跑把每个子任务的结果持久化到任务状态表标记completed恢复时只重跑pending和failed的子任务。同时在状态机里增加了一个resume动作让用户可以说从报销单第48张继续调度层能精准定位断点。这次排查让我明白一个道理聊天机器人可以无状态工作伙伴必须有状态。没有状态机兜底的任务调度在真实企业环境里就是定时炸弹。4.3 现场三知识库回答张冠李戴根子不在模型在召回业务方问员工年假政策是什么AI回答的是产假政策数据全部来自知识库置信度还不低。我查了RAG链路发现向量检索的top_k3里只有一篇文档真正讲了年假其他两篇是产假和育儿假模型从多数派里学坏了。排查后发现两个问题一是知识库里文档切分太粗一篇政策文件被切成了几个互相重复的块二是检索打分没有考虑文档类型权重制度类的权威性没体现出来。我后来做了三件事文档块按章节重新切分检索时加入元数据过滤比如政策类和案例类分开模型生成时要求标注引用的文档编号。改完后AI在制度问答上的准确率从72%升到94%。知识库质量问题不解决AI再强也是白搭。4.4 事后复盘三个可复用的排查清单现在团队内部有一套固定的AI应用问题排查清单也写进了开源文档症状优先排查项常用修复手段AI回答偏离业务事实检索召回内容、上下文拼接顺序调整切分粒度、加元数据过滤、限制引用来源工具调用结果明显不对入参schema校验、工具返回解析、字段映射一次只调一个工具、入参严格校验任务执行到一半中断子任务状态记录、超时策略、失败重试次数加断点续跑、状态持久化、降级人工工单这套清单帮了我大忙也推荐所有做企业AI落地的人维护一份自己的排查手册。5. 开源实践我放出去的东西长什么样、怎么搭最快代码放出去一段时间了也收到不少issue。这个章节我把仓库里的真实结构、最快部署路径和接入建议写清楚方便大家少走弯路。5.1 仓库结构与模块说明整个仓库是单体仓库分四个包work-partner/ ├── core/ # 调度层、状态机、任务管理 ├── agents/ # GPT-6的意图拆解、总结、校验 prompty 模板 ├── tools/ # 工具适配器邮件、文档、CRM、ERP等 ├── memory/ # 工作记忆、项目记忆、偏好记忆三套存储 └── ui/ # 简单的Web控制台管理任务、看日志我个人强烈建议先把core和memory跑通再去折腾工具适配器。工具是无穷无尽的但调度和记忆是地基。地基稳了上面长什么都行。5.2 本地最快部署路径二十分钟跑通查订单—发邮件部署依赖其实不多Python3.11、Redis存工作记忆、Postgres存任务状态和偏好记忆、向量库项目记忆用我在仓库里默认配了本地文件模式方便零依赖测试。启动顺序是拷贝仓库安装依赖pip install -r requirements.txt配置.env里模型API的keyGPT-6相关参数按模型服务商文档填启动Redis和Postgres执行数据库迁移脚本运行python work_partner/cli.py进入交互模式CLI里内置了一个演示工具集query_order_status查订单、send_email_to_customer发邮件、search_documents搜文档。你可以直接输入帮我查一下订单XC1001的状态如果已发货就把物流单号发给对应的客户系统会打印出完整的任务计划和执行轨迹你能看到GPT-6拆解了哪几步、每一步调了什么工具、最终生成了什么邮件草稿。5.3 接入真实企业系统的推荐路径开源版本接真实系统时我建议按以下顺序来先接只读工具查数据、搜文档不要一上来就接写操作。每个工具配上独立的鉴权凭证别用共享的超级账号。在工具适配器里加一层人工审批钩子凡是涉及对外发送、修改数据的动作默认挂起等审批。稳定运行两周以后再逐步放开发送权限。这套渐进式接入的思路看起来保守其实是最快的。因为一旦出了信任事故AI工具在企业内部的推广基本就宣告死亡宁稳勿快。6. 开源背后真正的门槛数据安全与权限模型的取舍把代码开源被人看得见的只是冰山一角。真正难的是我前面反复提到的权限模型、数据脱敏、可观测性。这三点做不好你甚至没法让法务同意你放代码。6.1 为什么开源要留一手业务无关但安全相关开源版本里我故意没有放任何企业真实系统的适配器只留了演示用的mock工具。原因其实很直接每个企业的权限模型都不一样放一个通用实现出来反而会误导别人。真正有价值的是权限校验的抽象接口——你只要实现check_permission(user_id, tool_name, params)这个方法调度层就会在每次工具调用前自动校验。这个抽象接口我在仓库里注释写得特别详细因为我觉得这才是开源的核心价值不是给你一套能跑的代码而是给你一套能长在你自己企业安全体系上的插槽。某开发者来信说他们花了两天把一个遗留OA系统接上来最重要的改动就是实现了这个权限接口。6.2 可观测性AI应用debug的救命稻草企业内部用AI最怕的是看着像人话实际在瞎编。我在仓库里为每个任务生成了一个trace ID贯穿整个生命周期用户请求 → 意图包 → 计划步骤 → 每个工具调用的请求/返回 → 每步的token数 → 最终回复全部落到日志和审计表。用户只需要把trace ID发给管理员管理员就能看到这个回答是怎么一步步产生的。这套可观测性在企业落地里是刚需我见过太多AI项目死在无法追责上。最后说一点个人体会。这个项目做下来我最大的感受是大模型本身的能力已经远超大多数企业的应用水平真正的瓶颈在于把它嵌进业务流程里的那一层胶水——任务编排、权限管控、记忆管理、过程审计。GPT-6确实让模型更聪明了但更聪明的模型和更靠谱的工作伙伴之间还隔着大量脏活累活。开源这套东西希望正在做同样事情的人能少走几步弯路。如果你正在企业内部搞AI落地建议先从我这个框架的调度层和记忆系统看起那才是真正能救命的代码。