最近被问得最多的一个问题不是“大模型能干什么”而是“传统软件架构是不是真的要完了”。我的态度一直很明确与其说终结不如说正在被重构。通用Agent的兴起确实在动摇过去二十多年我们习以为常的分层架构、状态机交互、硬编码流程未来软件的形态大概率会收敛成三件事大脑负责理解与决策技能负责执行与落地护栏负责安全与边界。这篇博文我会结合自己实操过的Agent化项目把这三层拆开揉碎讲清楚原理、落地路径和踩坑记录适合正在做架构设计的技术负责人、被业务部门追着要智能体的开发者以及所有对软件走向好奇的人。1. 传统软件架构的边界是怎么一步步失效的1.1 交互逻辑变了从“页面表单”到“自然语言意图”过去我们设计软件第一件事是画页面原型第二件事是定义表单字段第三件事是把用户的每一次点击映射成一条后端接口。整个架构的核心假设是用户知道自己想要什么并且愿意通过固定路径去得到它。所以我们需要菜单、按钮、弹窗、流程图需要把复杂的业务流程拆解成一步步操作。但Agent出现后这个假设松动了。用户不再需要理解系统的功能结构只需要用一句话表达意图剩下的路径规划、工具选择、参数填充、异常处理都由模型来完成。有一次我和团队改造一个内部工单系统业务方提的需求是“我希望直接说‘帮我查一下上个月所有未关闭的故障单按优先级排一下’系统自己就能把事情办了”。这个需求放在传统架构里意味着要做查询页面、要加排序控件、要把“未关闭”“上个月”这类模糊语义映射到数据库筛选条件工作量至少两周。在Agent框架里我们要做的只是把查询能力封装成一个技能然后让模型去理解意图、翻译参数、调用技能。开发周期从两周变成半天这个对比非常直观。1.2 逻辑承载变了从“代码流程”到“模型推理”传统软件里业务流程是预编译的。开发人员把“先校验权限、再检查库存、然后扣款、最后发通知”写死在代码里用户只能在预设的泳道内行动。好处是可控、可测、可审计坏处是每一条新流程都等于一次新的开发需求业务侧的灵活性和IT侧的交付效率永远在打架。Agent架构把流程控制权交给了大模型。模型根据上下文现场推理决定先调用哪个技能、参数怎么填、结果不满意要不要重试。这不是说代码不重要了而是代码的核心职责从“定义流程”变成了“定义能力边界和约束”。我经常用一个类比传统架构是编好剧本让演员按词走位Agent架构是给演员一个目标、一堆道具和几条禁忌让他在舞台上自己临场发挥。后者的上限更高但对舞台管理护栏和演员素质模型能力的要求也完全不一样。1.3 状态管理变了从“数据库为中心”到“上下文与记忆”传统系统的状态是明确的用户登录状态存在会话里业务数据存在关系库里进度状态存在状态字段里。数据是唯一的真相源逻辑通过事务保证一致性。Agent系统里的状态则分散得多——模型上下文里的对话历史、技能调用后返回的临时结果、长期记忆里沉淀的用户偏好、外部系统里真实的数据变更这四者之间有天然的同步鸿沟。最典型的一个坑模型在上下文里“以为”自己已经把数据写进数据库了实际上技能调用因为权限问题失败了模型却没有把这个失败信号当回事继续基于错误假设回复用户。这种状态错乱在传统架构里几乎不可能出现因为数据库事务要么提交要么回滚逻辑上一清二楚。在Agent架构里“上下文中的信息”和“真实世界的信息”是两套状态必须靠设计手段去弥合。1.4 变更成本变了从“改代码发版”到“优化描述和技能”传统软件改一条业务规则要走需求评审、开发、测试、发布的完整链路。Agent架构在理想状态下改一条规则等于优化一次提示词或者调整一次技能描述几个人一天就能完成。我和某团队合作过一个合同审核项目业务人员发现审核标准漏掉了“履约保函金额不得低于合同总额的10%”这一条。在旧系统里这是核心逻辑变更需要排期开发。在Agent系统里他们只是在审核规范文档里加了一行描述然后补充了对应的计算技能当天下午新规则就开始生效。这背后的代价是系统性风险后移变更变快了但每一次“改个描述”实际上都在修改模型的决策依据影响范围比改代码更难预测。这正好解释了为什么护栏层会成为未来架构里最核心的一层——不是为了限制Agent而是为了让快速迭代不失控。2. “大脑技能护栏”的实质拆解2.1 大脑不只是API调用而是完整的决策循环所谓大脑不是简单地接一个大模型的API然后把用户问题丢进去。真正可用的大脑至少要具备四个能力意图理解用户到底想干什么、任务规划把复杂目标拆成可执行的步骤、工具选择每个步骤该调用哪个技能、结果反思执行结果是否真的解决了问题需不需要重试。这四个能力组合在一起业界通常称之为Agent循环核心是ReAct模式的工程化——让模型交替进行推理Reasoning和行动Acting每拿到一个工具结果都重新评估下一步。这里有一个很反直觉的点模型不是越大越好。我们做过对比在很多垂直场景里一个经过精心调校的中型模型配合结构良好的技能定义效果往往超过直接上最大的通用模型。原因很简单——大模型的推理能力强但更容易在开放场景里“想太多”反而偏离业务约束。大脑的核心不是参数规模而是决策质量和可控性之间的平衡这也是为什么很多成熟的Agent框架都支持多模型路由简单意图用快模型复杂推理用强模型成本和质量同步优化。2.2 技能把一切能力变成标准化的“可调用工具”技能层是大脑和物理世界之间的桥梁。一个技能可以是一个API调用、一段数据库查询、一条RPA流程、一个代码解释器甚至是一个需要人工审批的流程——只要能用统一的接口描述清楚“这个工具是干什么的、需要哪些参数、会返回什么结果”它就可以被当作技能接入Agent。什么算一个好的技能定义我总结过三个标准。第一意图边界清晰技能描述要写清楚“适合解决什么问题、不适合解决什么问题”减少模型乱调用的概率。第二参数描述完备每个参数要有类型、取值范围、默认值、是否必填最好给一两个示例值。不要觉得这是小事模型对参数的填充错误是Agent系统里最常见的失败原因之一。第三返回结构稳定无论成功失败返回的数据结构要保持统一并且显式标注执行状态方便大脑判断下一步。市面上现在有不少技能协议标准核心思路其实是把“模型如何调用工具”这件事规范化。你可以理解为技能层就是给大脑装了一排有标准接口的机械臂大脑不需要关心机械臂内部的液压系统怎么工作只需要知道它能抓什么、怎么下指令、结果如何反馈。职责分离才是Agent架构能落地的关键。2.3 护栏决定Agent能不能长期跑在生产环境的分水岭很多团队做Agent Demo做得很快一上生产就翻车问题几乎都出在护栏层。护栏不是一个单一的组件而是一整套从提示词到执行环境的约束体系。最外层是提示词与系统约束告诉模型什么东西不能做、什么边界不能越类似给员工发一份行为守则。往里是技能级护栏包括白名单机制Agent只能调用被授权的技能、参数校验技能参数必须先过规则引擎再执行、敏感操作二次确认涉及删除、修改、转账等操作必须返回给用户确认。再往里是执行环境隔离Agent执行的代码应该跑在沙箱里访问外部资源要经过网关鉴权不能在业务网络里裸奔。最底层的护栏实际上是可观测性——所有决策轨迹、工具调用、参数快照都要留痕否则出了事故根本无法复盘。我见过最典型的生产事故是某个Agent因为上下文里出现了一条伪造的指令试图调用工资查询技能并批量导出数据。表面上看是模型安全性的问题根子上是护栏缺失——既没有对技能调用做权限分级也没有对批量查询做频率限制还没有针对敏感操作设置审批节点。如果三层护栏有一个在起作用这次事故都不会发生。3. 实操参考把一个传统系统改造成Agent架构3.1 第一步盘点业务域先找出“技能化”的最佳候选不要一上来就想着全系统改造先把业务梳理一遍找出最容易被Agent增强的环节。我建议用三个标准筛选流程是否高频重复、是否依赖自然语言理解、原有逻辑是否经常因为规则调整而变更。符合这三条的业务Agent化之后的价值最大见效最快。我们当时选择的是客服工单分类与路由。旧流程是人工读单、判断分类、指派处理人不仅慢而且不同人分类标准不一致。改造的第一步是把原有的分类规则、工单模板、处理人列表梳理出来封装成一个技能集合包括“获取工单详情”“查询历史同类工单”“根据规则匹配分类”“创建派单记录”四个技能。这一步不做任何模型层面的工作先把“技能”准备好。3.2 第二步设计技能描述这一步直接决定调用准确率技能描述写不好再强的模型也会乱来。拿“查询历史同类工单”这个技能举例我们初期写的描述是“用于查询历史工单”结果模型经常在没有参数的情况下调用或者拿查询结果去回答一些完全无关的问题。后来我们按照标准格式重写了描述{ name: query_similar_tickets, description: 查询与当前工单标题或内容相似的历史工单记录用于辅助分类和推荐处理方案。当用户提到以前遇到过、历史同类、参考之前怎么处理时优先调用。, parameters: { type: object, properties: { keyword: { type: string, description: 用于模糊匹配的关键词通常取自工单标题的核心词必填。 }, limit: { type: integer, description: 最多返回的记录条数默认5最大20。 }, status: { type: string, enum: [open, closed, pending], description: 按工单状态过滤可选不填则返回全部状态。 } }, required: [keyword] } }这里有个细节值得提技能描述里我们明确写上了“什么场景下优先调用”这句约束看起来不起眼实际上能大幅降低误用率。原因是模型对工具的选择主要依赖语义匹配你替它把使用场景圈出来它的选择精度自然就上去了。后来我们把所有技能定义都按这个模板重写一遍后工具调用的正确率从71%涨到了89%。3.3 第三步搭建Agent调度核心明确决策循环调度核心不一定要用重量级框架我们一开始用的是轻量级实现核心就是一个循环函数def agent_loop(user_input, context, max_iterations5): messages build_messages(user_input, context) for step in range(max_iterations): response llm.chat(messages, toolsavailable_skills) message response.message if message.tool_calls: messages.append(message) for tool_call in message.tool_calls: result execute_tool(tool_call.name, tool_call.arguments) messages.append({ role: tool, tool_call_id: tool_call.id, content: result }) continue return message.content return 已达最大迭代次数请精简问题或联系人工处理几个参数值得解释一下。max_iterations5是任务分解深度的上限防止模型陷入无限循环。迭代次数不是越多越好我们发现绝大多数工单场景三次工具调用内就能解决设置上限还能倒逼模型更高效地规划。memory的设计也要注意——不是把所有历史都塞进上下文而是把用户画像、最近对话摘要、上一次执行的结论压缩成结构化数据每一步都在减少上下文膨胀的风险。3.4 第四步护栏落地按风险等级分层控制任务调度跑通只是第一步真正能上生产靠的是护栏层。我们当时把技能调用按风险分成了L0、L1、L2三个等级。L0是无害查询Agent凭意图自由调用L1是涉及数据写入的操作必须带上一轮用户明确确认的上下文才能执行L2是高风险操作比如批量删除、数据导出直接不让Agent自动执行只能生成待人工审批的工单。在代码层面这个分级是一个简单但严格路由# 部分高风险技能的调用需要用户确认标记 TOOL_RISK_LEVEL { query_similar_tickets: L0, create_ticket_note: L1, batch_export_tickets: L2, } def execute_tool(name, arguments, user_confirmedFalse): risk TOOL_RISK_LEVEL.get(name, L1) if risk L2 and not user_confirmed: return { status: requires_confirmation, message: 该操作需要用户确认后才能执行, confirmation_token: generate_token() } if risk L1 and user_confirmed not in arguments: return {status: error, reason: 缺少用户确认标记} # 正常执行逻辑不要觉得这种设计限制了Agent的“智能”。恰恰相反明确的边界让模型不用犹豫“这个操作能不能做”反而能把精力集中在“怎么做才能满足用户需求”上这是一种双赢。3.5 第五步日志、评测与迭代闭环Agent系统的上线不是终点。我们搭建了一套“决策轨迹回放”机制每一次用户请求从意图识别到工具调用到最终回复全部按照时间线落盘。运营团队可以直接查看某个工单为什么被分配到了某个组、模型在中间环节调用过哪些技能、参数是什么、结果如何。这套机制带来的价值远超预期——很多模型行为问题靠回放一眼就能定位不用靠猜。评测集的建设同样重要。我们把历史一个季度的工单数据整理成200个典型场景每个场景都有标准答案和执行路径。任何一次技能描述修改、模型版本升级、参数调整都要先在评测集上跑一遍回归。上线后被吐槽最多的“怎么突然变笨了”类问题80%以上都是因为没做回归评测模型更新或描述变更后行为漂移了。4. 常见问题与排查技巧实录4.1 工具调用乱象模型总在错误场景调用技能现象用户只是问了一句“工单系统的响应时间怎么这么慢”Agent竟然调用了“创建工单”技能真的给用户建了一张投诉单。排查思路先看决策轨迹里模型的完整推理过程确认是技能描述不清晰还是模型上下文信息缺失。大部分情况下是技能描述里没有写明“不适合什么场景”模型对用户的情绪化表达做了过度解读。解决方法在技能描述里主动补上限制场景比如“本技能仅用于创建正式工单不用于回答性能咨询”。注意措辞用“仅用于”比“不要用于”更有效。实测发现正向限定比负向禁止更符合模型的语言理解习惯禁止类描述容易被模型忽略。4.2 上下文越滚越大成本呈指数级上涨现象Agent每多一轮工具调用token消耗就翻一倍一个简单的报销审批流程成本比预期高了好几倍。排查思路打开一次完整会话的token消耗明细你会发现问题往往出在“工具返回结果太长模型每次决策都把完整历史重读一遍”的组合上。尤其是查询类技能返回一个几百行的表单模型每一轮都要重新读一遍。解决方法工具返回做截断摘要还是拿查询工单举例后端返回原始数据后先让一个轻量模型压缩成结构化的三层摘要结论、明细概览、原始数据入口再喂给决策模型。操作上就是查询函数里加一个摘要步骤把5000字的返回压到不到500字。成本立刻降下来决策质量反而提升了——信息噪音少了。4.3 Agent陷入死循环同一个技能反复调用现象模型不断调用“查询库存”然后报告“库存不足”然后再次调用“查询库存”完全不尝试其它技能。排查思路这类问题通常是任务规划的盲点——模型只知道一个技能可以用不知道还有备选路线。说白了是技能库里没有给它足够的“逃生通道”。解决方法两条路并行。第一引入反思机制要求模型在连续两次调用相同技能且结果不变时输出“当前方案无效需要切换策略”的中间推论强制它跳出死胡同。第二给技能库补充一个“兜底技能”比如“联系人工处理”让模型在规划不下去的时候有台阶下。我们的实测结果加上这两层之后循环类问题减少了七成。4.4 护栏误伤正常操作被安全策略拦截现象用户提交一个完全合规的批量导出申请系统因为“缺少确认标记”拒绝了用户和业务方都很不满。排查思路这类问题通常是护栏设计过于依赖模型自觉。模型可能在中途重新组织语言把用户确认的信息放在了上下文的某个角落没有按预期格式传递给工具层。解决方法把确认流程从模型的自由对话里剥离出来变成界面层的强约束。比如需要L2权限的操作前端直接弹出一个二次确认框用户在框里勾选“我已知晓导出风险”把确认token作为接口参数传入不过模型转述。也就是说涉及安全边界的交互能不用模型就不用模型让流程系统自己闭环。4.5 模型升级后行为漂移原本好用的Agent突然“变笨”现象某次基础模型版本更新后没有改任何业务代码和技能定义但工具调用的准确率明显下降。排查思路大模型的版本更新并不承诺工具调用行为完全一致语义理解偏好可能漂移。这不是bug是常态。解决方法所以前面强调的回归评测集一定要建。我们后来把模型版本的升级流程固化为先在评测集上跑一轮对比重点观察工具选择准确率、参数填充完整率、拒绝调用频次三个指标分数达标才允许灰度上线。每一条技能描述也在评测记录里标注“适配的模型版本范围”防止下次升级后无声踩坑。5. 从项目实战角度看这套架构到底带来什么改变如果只看单点效率Agent替代人工确实很快。但我们团队在项目里体会更深的是另一个层面的变化——软件迭代的逻辑从“预测需求”变成了“定义边界”。过去做软件要尽可能预测用户的所有操作路径然后把路径做成功能菜单。现在做软件只要把“技能”做得足够规范、把“护栏”定得足够清晰剩下的路径探索和组合模型会动态完成。这意味着业务侧的个性化需求不再一定需要排期开发调整描述和配置就能实现。我也必须说实话这套架构不是银弹。在需要极致性能、强一致性、严苛审计的场景里传统架构依然不可替代哪怕Agent再强大也不能让模型替你去计算每秒百万级的交易流水。但从更长远的趋势看凡是依赖“语义理解规则匹配路径规划”的业务场景Agent化几乎是确定性的方向。将来你手里的软件可能真的就像三个盒子一个负责想一个负责做一个负责守住底线。作为技术人尽早理解这三层的关系比纠结于“谁取代谁”要务实得多。
最近被问得最多的一个问题不是“大模型能干什么”而是“传统软件架构是不是真的要完了”。我的态度一直很明确与其说终结不如说正在被重构。通用Agent的兴起确实在动摇过去二十多年我们习以为常的分层架构、状态机交互、硬编码流程未来软件的形态大概率会收敛成三件事大脑负责理解与决策技能负责执行与落地护栏负责安全与边界。这篇博文我会结合自己实操过的Agent化项目把这三层拆开揉碎讲清楚原理、落地路径和踩坑记录适合正在做架构设计的技术负责人、被业务部门追着要智能体的开发者以及所有对软件走向好奇的人。1. 传统软件架构的边界是怎么一步步失效的1.1 交互逻辑变了从“页面表单”到“自然语言意图”过去我们设计软件第一件事是画页面原型第二件事是定义表单字段第三件事是把用户的每一次点击映射成一条后端接口。整个架构的核心假设是用户知道自己想要什么并且愿意通过固定路径去得到它。所以我们需要菜单、按钮、弹窗、流程图需要把复杂的业务流程拆解成一步步操作。但Agent出现后这个假设松动了。用户不再需要理解系统的功能结构只需要用一句话表达意图剩下的路径规划、工具选择、参数填充、异常处理都由模型来完成。有一次我和团队改造一个内部工单系统业务方提的需求是“我希望直接说‘帮我查一下上个月所有未关闭的故障单按优先级排一下’系统自己就能把事情办了”。这个需求放在传统架构里意味着要做查询页面、要加排序控件、要把“未关闭”“上个月”这类模糊语义映射到数据库筛选条件工作量至少两周。在Agent框架里我们要做的只是把查询能力封装成一个技能然后让模型去理解意图、翻译参数、调用技能。开发周期从两周变成半天这个对比非常直观。1.2 逻辑承载变了从“代码流程”到“模型推理”传统软件里业务流程是预编译的。开发人员把“先校验权限、再检查库存、然后扣款、最后发通知”写死在代码里用户只能在预设的泳道内行动。好处是可控、可测、可审计坏处是每一条新流程都等于一次新的开发需求业务侧的灵活性和IT侧的交付效率永远在打架。Agent架构把流程控制权交给了大模型。模型根据上下文现场推理决定先调用哪个技能、参数怎么填、结果不满意要不要重试。这不是说代码不重要了而是代码的核心职责从“定义流程”变成了“定义能力边界和约束”。我经常用一个类比传统架构是编好剧本让演员按词走位Agent架构是给演员一个目标、一堆道具和几条禁忌让他在舞台上自己临场发挥。后者的上限更高但对舞台管理护栏和演员素质模型能力的要求也完全不一样。1.3 状态管理变了从“数据库为中心”到“上下文与记忆”传统系统的状态是明确的用户登录状态存在会话里业务数据存在关系库里进度状态存在状态字段里。数据是唯一的真相源逻辑通过事务保证一致性。Agent系统里的状态则分散得多——模型上下文里的对话历史、技能调用后返回的临时结果、长期记忆里沉淀的用户偏好、外部系统里真实的数据变更这四者之间有天然的同步鸿沟。最典型的一个坑模型在上下文里“以为”自己已经把数据写进数据库了实际上技能调用因为权限问题失败了模型却没有把这个失败信号当回事继续基于错误假设回复用户。这种状态错乱在传统架构里几乎不可能出现因为数据库事务要么提交要么回滚逻辑上一清二楚。在Agent架构里“上下文中的信息”和“真实世界的信息”是两套状态必须靠设计手段去弥合。1.4 变更成本变了从“改代码发版”到“优化描述和技能”传统软件改一条业务规则要走需求评审、开发、测试、发布的完整链路。Agent架构在理想状态下改一条规则等于优化一次提示词或者调整一次技能描述几个人一天就能完成。我和某团队合作过一个合同审核项目业务人员发现审核标准漏掉了“履约保函金额不得低于合同总额的10%”这一条。在旧系统里这是核心逻辑变更需要排期开发。在Agent系统里他们只是在审核规范文档里加了一行描述然后补充了对应的计算技能当天下午新规则就开始生效。这背后的代价是系统性风险后移变更变快了但每一次“改个描述”实际上都在修改模型的决策依据影响范围比改代码更难预测。这正好解释了为什么护栏层会成为未来架构里最核心的一层——不是为了限制Agent而是为了让快速迭代不失控。2. “大脑技能护栏”的实质拆解2.1 大脑不只是API调用而是完整的决策循环所谓大脑不是简单地接一个大模型的API然后把用户问题丢进去。真正可用的大脑至少要具备四个能力意图理解用户到底想干什么、任务规划把复杂目标拆成可执行的步骤、工具选择每个步骤该调用哪个技能、结果反思执行结果是否真的解决了问题需不需要重试。这四个能力组合在一起业界通常称之为Agent循环核心是ReAct模式的工程化——让模型交替进行推理Reasoning和行动Acting每拿到一个工具结果都重新评估下一步。这里有一个很反直觉的点模型不是越大越好。我们做过对比在很多垂直场景里一个经过精心调校的中型模型配合结构良好的技能定义效果往往超过直接上最大的通用模型。原因很简单——大模型的推理能力强但更容易在开放场景里“想太多”反而偏离业务约束。大脑的核心不是参数规模而是决策质量和可控性之间的平衡这也是为什么很多成熟的Agent框架都支持多模型路由简单意图用快模型复杂推理用强模型成本和质量同步优化。2.2 技能把一切能力变成标准化的“可调用工具”技能层是大脑和物理世界之间的桥梁。一个技能可以是一个API调用、一段数据库查询、一条RPA流程、一个代码解释器甚至是一个需要人工审批的流程——只要能用统一的接口描述清楚“这个工具是干什么的、需要哪些参数、会返回什么结果”它就可以被当作技能接入Agent。什么算一个好的技能定义我总结过三个标准。第一意图边界清晰技能描述要写清楚“适合解决什么问题、不适合解决什么问题”减少模型乱调用的概率。第二参数描述完备每个参数要有类型、取值范围、默认值、是否必填最好给一两个示例值。不要觉得这是小事模型对参数的填充错误是Agent系统里最常见的失败原因之一。第三返回结构稳定无论成功失败返回的数据结构要保持统一并且显式标注执行状态方便大脑判断下一步。市面上现在有不少技能协议标准核心思路其实是把“模型如何调用工具”这件事规范化。你可以理解为技能层就是给大脑装了一排有标准接口的机械臂大脑不需要关心机械臂内部的液压系统怎么工作只需要知道它能抓什么、怎么下指令、结果如何反馈。职责分离才是Agent架构能落地的关键。2.3 护栏决定Agent能不能长期跑在生产环境的分水岭很多团队做Agent Demo做得很快一上生产就翻车问题几乎都出在护栏层。护栏不是一个单一的组件而是一整套从提示词到执行环境的约束体系。最外层是提示词与系统约束告诉模型什么东西不能做、什么边界不能越类似给员工发一份行为守则。往里是技能级护栏包括白名单机制Agent只能调用被授权的技能、参数校验技能参数必须先过规则引擎再执行、敏感操作二次确认涉及删除、修改、转账等操作必须返回给用户确认。再往里是执行环境隔离Agent执行的代码应该跑在沙箱里访问外部资源要经过网关鉴权不能在业务网络里裸奔。最底层的护栏实际上是可观测性——所有决策轨迹、工具调用、参数快照都要留痕否则出了事故根本无法复盘。我见过最典型的生产事故是某个Agent因为上下文里出现了一条伪造的指令试图调用工资查询技能并批量导出数据。表面上看是模型安全性的问题根子上是护栏缺失——既没有对技能调用做权限分级也没有对批量查询做频率限制还没有针对敏感操作设置审批节点。如果三层护栏有一个在起作用这次事故都不会发生。3. 实操参考把一个传统系统改造成Agent架构3.1 第一步盘点业务域先找出“技能化”的最佳候选不要一上来就想着全系统改造先把业务梳理一遍找出最容易被Agent增强的环节。我建议用三个标准筛选流程是否高频重复、是否依赖自然语言理解、原有逻辑是否经常因为规则调整而变更。符合这三条的业务Agent化之后的价值最大见效最快。我们当时选择的是客服工单分类与路由。旧流程是人工读单、判断分类、指派处理人不仅慢而且不同人分类标准不一致。改造的第一步是把原有的分类规则、工单模板、处理人列表梳理出来封装成一个技能集合包括“获取工单详情”“查询历史同类工单”“根据规则匹配分类”“创建派单记录”四个技能。这一步不做任何模型层面的工作先把“技能”准备好。3.2 第二步设计技能描述这一步直接决定调用准确率技能描述写不好再强的模型也会乱来。拿“查询历史同类工单”这个技能举例我们初期写的描述是“用于查询历史工单”结果模型经常在没有参数的情况下调用或者拿查询结果去回答一些完全无关的问题。后来我们按照标准格式重写了描述{ name: query_similar_tickets, description: 查询与当前工单标题或内容相似的历史工单记录用于辅助分类和推荐处理方案。当用户提到以前遇到过、历史同类、参考之前怎么处理时优先调用。, parameters: { type: object, properties: { keyword: { type: string, description: 用于模糊匹配的关键词通常取自工单标题的核心词必填。 }, limit: { type: integer, description: 最多返回的记录条数默认5最大20。 }, status: { type: string, enum: [open, closed, pending], description: 按工单状态过滤可选不填则返回全部状态。 } }, required: [keyword] } }这里有个细节值得提技能描述里我们明确写上了“什么场景下优先调用”这句约束看起来不起眼实际上能大幅降低误用率。原因是模型对工具的选择主要依赖语义匹配你替它把使用场景圈出来它的选择精度自然就上去了。后来我们把所有技能定义都按这个模板重写一遍后工具调用的正确率从71%涨到了89%。3.3 第三步搭建Agent调度核心明确决策循环调度核心不一定要用重量级框架我们一开始用的是轻量级实现核心就是一个循环函数def agent_loop(user_input, context, max_iterations5): messages build_messages(user_input, context) for step in range(max_iterations): response llm.chat(messages, toolsavailable_skills) message response.message if message.tool_calls: messages.append(message) for tool_call in message.tool_calls: result execute_tool(tool_call.name, tool_call.arguments) messages.append({ role: tool, tool_call_id: tool_call.id, content: result }) continue return message.content return 已达最大迭代次数请精简问题或联系人工处理几个参数值得解释一下。max_iterations5是任务分解深度的上限防止模型陷入无限循环。迭代次数不是越多越好我们发现绝大多数工单场景三次工具调用内就能解决设置上限还能倒逼模型更高效地规划。memory的设计也要注意——不是把所有历史都塞进上下文而是把用户画像、最近对话摘要、上一次执行的结论压缩成结构化数据每一步都在减少上下文膨胀的风险。3.4 第四步护栏落地按风险等级分层控制任务调度跑通只是第一步真正能上生产靠的是护栏层。我们当时把技能调用按风险分成了L0、L1、L2三个等级。L0是无害查询Agent凭意图自由调用L1是涉及数据写入的操作必须带上一轮用户明确确认的上下文才能执行L2是高风险操作比如批量删除、数据导出直接不让Agent自动执行只能生成待人工审批的工单。在代码层面这个分级是一个简单但严格路由# 部分高风险技能的调用需要用户确认标记 TOOL_RISK_LEVEL { query_similar_tickets: L0, create_ticket_note: L1, batch_export_tickets: L2, } def execute_tool(name, arguments, user_confirmedFalse): risk TOOL_RISK_LEVEL.get(name, L1) if risk L2 and not user_confirmed: return { status: requires_confirmation, message: 该操作需要用户确认后才能执行, confirmation_token: generate_token() } if risk L1 and user_confirmed not in arguments: return {status: error, reason: 缺少用户确认标记} # 正常执行逻辑不要觉得这种设计限制了Agent的“智能”。恰恰相反明确的边界让模型不用犹豫“这个操作能不能做”反而能把精力集中在“怎么做才能满足用户需求”上这是一种双赢。3.5 第五步日志、评测与迭代闭环Agent系统的上线不是终点。我们搭建了一套“决策轨迹回放”机制每一次用户请求从意图识别到工具调用到最终回复全部按照时间线落盘。运营团队可以直接查看某个工单为什么被分配到了某个组、模型在中间环节调用过哪些技能、参数是什么、结果如何。这套机制带来的价值远超预期——很多模型行为问题靠回放一眼就能定位不用靠猜。评测集的建设同样重要。我们把历史一个季度的工单数据整理成200个典型场景每个场景都有标准答案和执行路径。任何一次技能描述修改、模型版本升级、参数调整都要先在评测集上跑一遍回归。上线后被吐槽最多的“怎么突然变笨了”类问题80%以上都是因为没做回归评测模型更新或描述变更后行为漂移了。4. 常见问题与排查技巧实录4.1 工具调用乱象模型总在错误场景调用技能现象用户只是问了一句“工单系统的响应时间怎么这么慢”Agent竟然调用了“创建工单”技能真的给用户建了一张投诉单。排查思路先看决策轨迹里模型的完整推理过程确认是技能描述不清晰还是模型上下文信息缺失。大部分情况下是技能描述里没有写明“不适合什么场景”模型对用户的情绪化表达做了过度解读。解决方法在技能描述里主动补上限制场景比如“本技能仅用于创建正式工单不用于回答性能咨询”。注意措辞用“仅用于”比“不要用于”更有效。实测发现正向限定比负向禁止更符合模型的语言理解习惯禁止类描述容易被模型忽略。4.2 上下文越滚越大成本呈指数级上涨现象Agent每多一轮工具调用token消耗就翻一倍一个简单的报销审批流程成本比预期高了好几倍。排查思路打开一次完整会话的token消耗明细你会发现问题往往出在“工具返回结果太长模型每次决策都把完整历史重读一遍”的组合上。尤其是查询类技能返回一个几百行的表单模型每一轮都要重新读一遍。解决方法工具返回做截断摘要还是拿查询工单举例后端返回原始数据后先让一个轻量模型压缩成结构化的三层摘要结论、明细概览、原始数据入口再喂给决策模型。操作上就是查询函数里加一个摘要步骤把5000字的返回压到不到500字。成本立刻降下来决策质量反而提升了——信息噪音少了。4.3 Agent陷入死循环同一个技能反复调用现象模型不断调用“查询库存”然后报告“库存不足”然后再次调用“查询库存”完全不尝试其它技能。排查思路这类问题通常是任务规划的盲点——模型只知道一个技能可以用不知道还有备选路线。说白了是技能库里没有给它足够的“逃生通道”。解决方法两条路并行。第一引入反思机制要求模型在连续两次调用相同技能且结果不变时输出“当前方案无效需要切换策略”的中间推论强制它跳出死胡同。第二给技能库补充一个“兜底技能”比如“联系人工处理”让模型在规划不下去的时候有台阶下。我们的实测结果加上这两层之后循环类问题减少了七成。4.4 护栏误伤正常操作被安全策略拦截现象用户提交一个完全合规的批量导出申请系统因为“缺少确认标记”拒绝了用户和业务方都很不满。排查思路这类问题通常是护栏设计过于依赖模型自觉。模型可能在中途重新组织语言把用户确认的信息放在了上下文的某个角落没有按预期格式传递给工具层。解决方法把确认流程从模型的自由对话里剥离出来变成界面层的强约束。比如需要L2权限的操作前端直接弹出一个二次确认框用户在框里勾选“我已知晓导出风险”把确认token作为接口参数传入不过模型转述。也就是说涉及安全边界的交互能不用模型就不用模型让流程系统自己闭环。4.5 模型升级后行为漂移原本好用的Agent突然“变笨”现象某次基础模型版本更新后没有改任何业务代码和技能定义但工具调用的准确率明显下降。排查思路大模型的版本更新并不承诺工具调用行为完全一致语义理解偏好可能漂移。这不是bug是常态。解决方法所以前面强调的回归评测集一定要建。我们后来把模型版本的升级流程固化为先在评测集上跑一轮对比重点观察工具选择准确率、参数填充完整率、拒绝调用频次三个指标分数达标才允许灰度上线。每一条技能描述也在评测记录里标注“适配的模型版本范围”防止下次升级后无声踩坑。5. 从项目实战角度看这套架构到底带来什么改变如果只看单点效率Agent替代人工确实很快。但我们团队在项目里体会更深的是另一个层面的变化——软件迭代的逻辑从“预测需求”变成了“定义边界”。过去做软件要尽可能预测用户的所有操作路径然后把路径做成功能菜单。现在做软件只要把“技能”做得足够规范、把“护栏”定得足够清晰剩下的路径探索和组合模型会动态完成。这意味着业务侧的个性化需求不再一定需要排期开发调整描述和配置就能实现。我也必须说实话这套架构不是银弹。在需要极致性能、强一致性、严苛审计的场景里传统架构依然不可替代哪怕Agent再强大也不能让模型替你去计算每秒百万级的交易流水。但从更长远的趋势看凡是依赖“语义理解规则匹配路径规划”的业务场景Agent化几乎是确定性的方向。将来你手里的软件可能真的就像三个盒子一个负责想一个负责做一个负责守住底线。作为技术人尽早理解这三层的关系比纠结于“谁取代谁”要务实得多。
