1. 从能问答到能干活这次改造到底在填什么坑年初需求评审会业务方把一句话拍在桌上大模型不是挺能干嘛把每天的对账、异常单提醒和订单下发这些活也接过去吧。当时我们内部的大模型应用说白了还停留在问答和内容生成层面。能让模型把一份制度文档总结得漂漂亮亮但让它主动登录老ERP查一条订单状态它做不到。这个实践项目立项代号叫20.8方向非常明确基于Agent的插件化改造、系统对接和自动化任务全流程打通。我写这篇复盘一是给自己留个技术存档二是给准备做同类大模型从聊天框走向业务执行的团队一点路线参考。20.8项目最终做的事情用一句话概括把已有的文档问答大模型升级成一个能调用内外部系统、能跑多步任务、能自己处理异常并请求人工确认的Agent工作平台。整个改造从零到上线用了三个月其中最花时间的不是模型调优而是插件化底座设计和一连串跟老系统的沟通。1.1 模型是大脑但大脑没有手也没有腿大模型本身只有语言能力。它理解你说帮我查一下上周的采购订单但它不知道去哪查、用什么账号查、返回的数据怎么跟业务流程关联。所以Agent这个层必须补出来。Agent在这里做的事是拿着大模型这张大脑给它装上工具类插件、系统对接适配器、任务编排逻辑和记忆模块。每个插件解决一个具体的外部能力比如查订单、写审批单、发消息每个系统对接适配器解决某个业务系统的接口到底怎么调任务编排解决多步流程中先做什么后做什么。这也解释了为什么接入一个大模型API和让大模型跑通业务之间有巨大鸿沟。API只是给了你一个会说漂亮话的脑子Agent项目则是把脑子接到四肢上。没有插件化设计每加一个新系统就要改一遍主流程代码这是最早的教训。1.2 项目红线Agent不直接碰核心业务库所有写操作留审批口20.8项目启动前我给自己定了三条红线后来所有设计都绕着它们走第一Agent可以读任何授权范围内的业务数据但绝不直接写核心业务表。任何写操作必须落到一个独立的执行申请结构里由工具适配器或人工确认后再转发给业务系统。第二所有Agent动作必须有可审计的日志。模型调用哪个工具、传了什么参数、拿到了什么结果、是否重试过每一步都要能查。这不仅是技术要求也是业务安全要求。第三自动化不等于无人化。单据提交、付款、订单下发这类影响交易的动作可以自动生成建议、自动填单但最终确认保留给人。真正完全无人值守的只开放给低风险的只读类巡检。这三条红线给后面带来了一个直接收益业务方愿意把更多接口开放给我们试。因为他们知道就算Agent判断错了最坏情况下也会在人工审批环节被拦住不会直接污染业务数据。2. 插件化底座设计工具分层、注册表和技能包组合很多团队做Agent第一版是把提示词写长一点把所有工具说明塞进System Prompt。工具少的时候这招还能用工具一旦超过15到20个模型就开始频繁选错工具、传错参数。我在20.8的早期原型里就吃过这个亏后来不得不把插件化底座拆成三层。2.1 工具注册表新插件不碰主流程第一层是工具层。每个对接能力都封装成一个标准Tool类里面包含工具名称、描述、入参Schema、执行方法、权限级别和幂等键逻辑。工具写好之后通过注册表挂载到Agent运行环境里主流程代码完全不需要改动。当时定下的工具类长这样代码只是一个简化示意# plugin_base.py from dataclasses import dataclass, field from typing import Any, Callable, Optional import time, uuid dataclass class ToolContext: trace_id: str # 每轮任务唯一的追踪ID operator: str # 操作者标识可能是人也可能是定时任务 request_id: str # 幂等键防止重复执行 extra: dict field(default_factorydict) class BaseTool: name: str description: str parameters: dict {} level: str read # read / write / critical def execute(self, params: dict, ctx: ToolContext) - dict: raise NotImplementedError注册工具的方式类似装饰器注册。每个新系统要接进来开发人员只需要写一个继承BaseTool的类在execute里实现真正的接口调用然后注册到工具中心。模型在Function Calling时看到的是工具有哪些、入参是什么、什么时候用实际情况由执行引擎统一做权限校验和审计。这套设计最大的好处是后面接入新系统时不用天天改Agent主控。主控只认标准工具协议新系统对接只是新增一个插件。2.2 技能与工具的分层不让模型在二十个工具里大海捞针工具层解决能调用什么但模型面对一堆工具时还会犯选择困难症。20个工具全塞给模型效果很差。后来我把上层拆出一个技能层或者叫Skill层。技能不是新工具它是工具提示词前置过滤规则的组合。比如财务对账异常处理是一个技能这个技能内部会依次调用查银行流水查业务单据生成差异报告创建审批事项这几个工具。Agent主控的第一决策不是选工具而是选技能。选完技能后技能内部再按照预设编排去调用工具。这套分层设计来自一个简单的观察让模型在高频场景里做决策不如让它在更少更明确的选择里做决策。技能包为每个高频任务写好了执行步骤模型只需要根据当前情况判断哪些步骤需要执行、哪些可以跳过而不是从零开始计划调哪个工具。2.3 技能包按场景挂载用完即卸载20.8上线后我们把工具中心里的插件按场景分成若干技能包。比如订单协同技能包里只有订单查询、下单、回传、状态同步这几个工具资金对账技能包又不同。每个任务进来后先走一个场景路由层路由层根据任务类型把对应的技能包注入模型上下文。这个做法让模型每次看到的工具数量从30个降到5到8个准确性提升非常明显。实测工具选择准确率从最初的88%左右提升到97%左右基本接近可用状态。如果你做Agent改造时发现模型总是选错工具先别急着怪模型回头数一数是不是一次塞给它的工具太多了。3. 对接老系统的三种姿势中间表、WebService、FTP文件20.8项目里最耗时间的不是模型是系统对接。我们面对的对接对象包括外部供应链系统、财务系统、供应商门户它们的状态大概是有数据库但不开放实时API、只提供老式SOAP接口、以及最原始的FTP文件交换。三种情况分别用了三种解法。3.1 中间表方案不开放API的老系统用一张桥接表解决碰到一个业务流程老系统对方IT说数据库可以给我们开只读账号但不可能开放写接口。可是我们恰恰需要让Agent帮业务方提交一些状态变更申请。最后用了中间表这个最朴素的办法。单独建一个Agent桥接库里面建了两类表一类是任务申请另一类是结果回执。Agent写任务申请老系统侧写一个定时轮询程序去消费这些申请执行完后把结果写回回执表。Agent再轮询回执表拿到执行结果。-- agent_bridge.task_apply CREATE TABLE task_apply ( id BIGINT AUTO_INCREMENT PRIMARY KEY, request_id VARCHAR(64) NOT NULL UNIQUE, -- 幂等键 task_type VARCHAR(64) NOT NULL, payload JSON NOT NULL, status VARCHAR(32) DEFAULT PENDING, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, handled_at DATETIME NULL ); -- agent_bridge.task_result CREATE TABLE task_result ( id BIGINT AUTO_INCREMENT PRIMARY KEY, request_id VARCHAR(64) NOT NULL, result_code VARCHAR(32), result_msg TEXT, result_data JSON, created_at DATETIME DEFAULT CURRENT_TIMESTAMP );Agent在这套机制里做的事情相当于一个业务员把申请单填好后投进窗口。老系统处理完再从窗口拿回执。这里有一个关键设计点request_id必须唯一。Agent一次任务可能因为网络中断而重试如果没有唯一ID同一个申请会被老系统处理两次。我把request_id由Agent执行引擎统一生成拿这个ID查是否已有处理结果有就直接返回不再重复提交。3.2 WebService适配器把XML折磨留给代码把友好描述留给模型另一个老系统提供的是SOAP WebService接口文档是十年前写的字段命名极其混乱。有的字段叫OrderID同类型字段在另一个接口里叫OrderNo再下一个接口里叫SO_NO。这种接口直接丢给Agent模型基本必错。我做的适配器做的事很简单底层使用SOAP客户端调用老接口解析XML响应把结果转成统一JSON结构。但暴露给模型的参数说明不是照着WSDL原样翻译而是人工整理成业务人员能理解的中文描述。比如老接口的入参里有Vendor实际指供应商编码我在工具Schema里就写成供应商编码以VC开头如VC10086并告诉模型如果不确定供应商编码先调用供应商查询工具查一下不要猜。这就是把系统对接时的字段歧义消化在适配器层不让模型去猜接口字段的潜规则。SOAP接口还有个常见坑返回报文里一旦有部分业务失败错误信息往往嵌在多层XML节点里模型如果只看到HTTP 200就会以为成功了。我的适配器会额外做一层业务成功判断把XML里嵌套的业务码、描述、明细结果全部解析出来只有业务码明确表示成功才返回成功否则返回可读的失败原因。3.3 FTP文件模式Agent也要学会等待异步回执供应商门户最原始只支持FTP文件交换。我们让Agent生成对账差异文件推到指定目录供应商系统定时下载处理再回传一个执行结果文件。没有同步接口Agent最大的挑战是不知道结果什么时候回来。我把每一次FTP下发都当成一个带状态的异步任务Agent推完文件后不立即判定成功而是生成一条等待记录然后通过定时任务检查结果文件目录。只要发现文件名匹配的回执就解析内容、更新任务状态并触发后续动作。这里给Agent设计的等待策略是最多等待24小时每30分钟检查一次超过时限进入人工处理队列。如果不设这个上限Agent可能会一直等下去任务永远悬在那里。三种对接方式各有适用场景我最后归纳成一个内部选型表对接方式实时性改造成本适用场景主要风险中间表轮询秒级到分钟级中老系统有数据库访问权限但不开放API表结构变更、并发冲突WebService适配器同步秒级中高系统提供SOAP/REST接口但字段混乱接口不稳定、字段隐含规则多FTP文件交换异步分钟到小时级中外部门户只支持文件交换文件命名冲突、结果回执延迟4. 自动化任务编排状态机、触发器和复盘记忆库插件和系统对接解决的是Agent能调什么自动化任务编排解决的是一件事怎么从第一步跑到最后一步。刚开始做时我天真地以为把任务描述写清楚让模型链式调用工具就行。实际上跑了两周就发现没有状态管理的Agent就像金鱼任务一长就忘了自己进行到哪了。4.1 任务状态机Agent不是一条直线跑到底每个自动化任务在我这里都有一个状态对象。它记录了任务当前处于哪个阶段、依赖哪些参数、已经拿到什么结果、失败了几次、下一步可以做什么。核心状态枚举大概是# task_state.py import enum class TaskState(enum.Enum): WAITING waiting # 排队等待 PLANNING planning # Agent正在拆解计划 RUNNING running # 正在执行工具调用 WAIT_CONFIRM wait_confirm # 等待人工确认 WAIT_RESULT wait_result # 等待外部系统异步回执 SUCCEEDED succeeded # 执行成功 FAILED failed # 执行失败 CANCELLED cancelled # 人工取消每次Agent执行一个工具后引擎会把结果写到任务状态里而不是把所有中间结果都堆在模型上下文里。后面的Agent决策只读取当前状态关键结论避免越跑越糊涂。拿一个供应商账单异常处理的真实流程举例。定时任务每天凌晨触发后Agent会先读取当天的对账差异清单再调用工具逐条查询对应单据判断差异类型。如果是单价差异且金额较小Agent会生成一张调整单草稿并置为等待确认状态业务人员在页面上点确认后任务状态流转回RUNNINGAgent再去调用提交接口。整个过程中Agent不需要记住全部明细它只需要在每一步拿到当前待处理记录ID和已完成结论。4.2 三种任务触发方式定时、事件和人工对话自动化任务不是只有定时触发这一种。我按来源把触发方式分成了三类各有各的设计定时任务适合固定节奏的巡检和报表。我用调度器统一管理每个定时任务执行时会带上一个调度ID方便和人工触发的任务区分。事件触发适合某个外部状态变了Agent需要跟进的场景。比如供应商在门户上更新了交期这个消息推送到消息队列后Agent会拉取变更内容判断是否需要通知内部计划员或调整后续排程。这里的重点是先做一次轻量级判断大部分事件都不需要进入全流程Agent否则成本和噪声都受不了。人工对话触发则是最灵活的入口。业务人员在IM里说一句帮我查下这个月还没回传的采购订单Agent解析后自动生成一个任务并执行。这种任务通常比较轻直接走只读工具链高权限操作还是按红线走人工确认。4.3 任务复盘库让Agent不在同一个坑里摔两次除了工具调用能力Agent的记忆机制直接决定它能否越用越顺。我在20.8里做了三层记忆临时记忆放在当前任务的上下文里任务结束即释放。长期记忆用向量库存业务常识和个人偏好比如财务部要求对账差异金额超过5万元必须人工审批这些信息在任务规划时会被检索出来注入提示词。还有一个容易被忽略的是任务复盘库每次任务失败或被人为纠正后Agent会把失败原因、修正动作、涉及的工具和参数保存成一条结构化记录。下次再来类似任务时执行引擎会做一次相似度检索把匹配到的复盘记录作为经验参考丢给模型。这个机制不是让模型多学习什么而是给它一份上次这里摔过的提醒。实际效果也很明显上线一个月后同类任务的失败率都往下降了。5. 上线后的故障复盘五个差点劝退我的问题20.8项目真正跑起来之后问题才接踵而来。这里挑五个有代表性的每一个都值得展开说。5.1 参数串号字段名相似模型把供应商ID当成了客户ID第一次事故是一笔订单被发给了错误的供应商。排查日志后发现模型调用下单工具时把supplierId和customerId搞混了。两个工具参数都接收以ID结尾的编码模型只看名字猜含义自然出问题。我的修复不是反复改提示词而是从工具设计上堵住漏洞。所有ID类参数禁止模型直接猜要求它先调用主数据检索工具拿到名称对应的ID候选再填入参数。如果检索结果有多个相似项模型必须列出候选让操作者确认。这相当于把自由填参改成了受控选择。5.2 重复提交接口超时后Agent自动重试产生了脏数据某次老系统接口响应超过10秒Agent按照策略自动重试了一次。结果第一次请求其实已经到达服务端只是响应超时第二次重试又生成了一单。业务侧看到两条完全一样的单据一度想下线功能。排查链路是这样的先翻任务日志定位到两次工具调用时间间隔5秒request_id不同。问题出在重试机制生成了新的request_id而服务端只能用request_id判重。修复方案是让Agent任务引擎在整个任务生命周期内复用同一个幂等键重试不换键并在服务端增加唯一约束。加完这个类似超时重试再也没有产生过重复数据。5.3 上下文漂移步骤一长Agent忘了刚刚的处理结论做长流程自动化时一个任务可能调用十几个工具、产生几十段日志和返回结果。把这些全部塞进模型上下文Token消耗大不说模型还会被无关信息干扰出现前后结论不一致的情况。我后来做了一个强制规则每个工具执行完Agent必须产出一段不超过200字的结构化小结包含拿到了什么、结论是什么、下一步建议是什么。后续模型只读这些小结不再看原始日志。这个做法很像人做项目时先写会议纪要再基于纪要推进下一步。对长任务效果立竿见影决策质量明显提升。5.4 本地小模型做工具调用没有想象中那么可靠因为部分业务数据敏感我们也尝试过用本地部署的开源模型承担工具调用任务。vLLM部署、Ollama部署都试过发现开源模型做总结、抽取类任务没问题但让它严格按照Function Calling格式输出工具调用错误率比商用模型高不少。经常出现参数结构对、但字段值给错或者一次性输出多个工具调用导致执行顺序错乱。最终架构做成了分工模式商用模型负责规划和工具调用本地模型负责私有数据的脱敏总结、PDF抽取和文本分类。自建模型如果要承担工具调用仅靠通用Prompt是不够的需要用工具调用的数据集做微调。一般团队没有这个精力我建议直接采用多模型分工谁擅长什么就让谁做什么。5.5 业务规则遗漏工具层不做校验提示词写得再好也没用有一次Agent生成的付款申请金额刚好超过审批阈值但它没走高级审批流程直接把单据提交了。原因是提示词里写了超过阈值要审批可阈值数字在业务系统里是个可配置参数提示词用了一个写死的旧值。这个教训之后我把所有跟金额、权限、状态相关的业务规则下沉到工具层和流程引擎层由代码硬校验不再寄希望于模型遵守。模型负责判断该不该做但能不能做、是否需要审批这类底线规则必须由代码保证。这里也建议你在设计插件化改造时提前整理一份规则清单把所有刚性的业务约束从模型侧剥离出来。6. 运行三个月后我对这套架构的真实评价到写这篇复盘时20.8平台已经稳定运行了一段时间。日均处理自动化任务几百次异常对账分析类任务的自动化完成率在80%以上单条对账处理时间从人工的半小时左右缩短到几分钟订单下发类任务虽然还需要人工确认但确认前的填单和校验基本都由Agent完成。从一个可能不太起眼但很关键的指标看人工在流程中被要求做的事从从头处理一件事变成了审核Agent已经做好的结果。这是这个项目最大的价值。6.1 重新来一次我会把预算和精力花在这些环节如果让我重新做一遍这个Agent化改造我会把更多时间花在数据字典整理和工具Schema设计上。模型能不能准确调用工具很大程度上取决于工具的说明书是否清晰。字段含义模糊、缺少示例、取值范围不明确的工具模型很难用对。另一个调整是更早地引入Mock模式。Agent调用外部系统前先能在本地用模拟数据跑通全流程。没有Mock每次测试都要依赖真实系统和真实数据排错极慢。还有一点是让业务方提前把人工介入点画出来。不要等技术上线了再讨论哪个环节要人确认。这一步想清楚Agent的自动化边界才清晰。6.2 个人体会Agent能跑多远看的是跑道画得有多清楚20.8项目中每次故障定位到最后极少是大模型变笨了更多是我对业务规则、接口约束、工具边界没有表达清楚。大模型像一个能力很强的实习生你给它一个模糊的岗位它会做出各种意想不到的事你给它一份清晰的SOP哪怕系统老一点、工具简陋一点它也能按部就班地跑起来。整个Agent平台里最有价值的资产其实不是模型也不是代码而是那套把业务能力插件化、把系统接口标准化、把任务边界定义清楚的过程。一旦这些沉淀下来后续接入新场景就会越来越顺。这篇复盘暂时写到这里后面如果继续深入我会重点聊聊工具集成测试的断言设计以及如何用仿真环境给Agent任务做回归验证。
