1. 控制权转移Agent 架构正在经历的一次身份重构最近圈里聊 Agent 的时候风向明显变了。一年前大家问得最多的是“用哪个 Agent 框架”“怎么编排多智能体”“工作流节点怎么连”现在挂在嘴边的变成了另一句话——“能不能让模型自己决定下一步干什么”这个转变非常微妙但影响深远。它本质上是在回答一个核心问题在 Agent 系统里到底谁说了算是工程师预设的流程逻辑还是模型基于上下文做出的动态判断我把这个趋势叫做“控制权回撤”。注意我用的是“回”字因为最早做 Agent 的时候大家就是靠模型一句话一句话地生成动作的。后来发现纯靠模型太飘不稳定、不可控于是开始上硬编码流程、状态机、工作流编排把模型的自由度牢牢圈起来。但圈到极致之后大家又发现另一个问题流程写死之后Agent 变成了一个只会按剧本走戏的演员稍微遇到点剧本外的情况就卡壳。于是控制权又开始往模型手里移动。这就像带孩子一开始放任自流结果闯了祸后来管得太严发现孩子完全失去了应变能力现在大家正在摸索的是那种“关键规则我来定具体怎么做事你说了算”的边界感。这个平衡点在哪正是当前 Agent 开发中最值得深耕的方向。1.1 从“人写流程”到“模型读流程”传统的 Agent 设计逻辑是自上而下的工程师画一张流程图A 节点做什么、B 节点做什么、如果出现条件 X 就跳转到 C 节点。这套思路在软件工程里非常成熟状态机、有限自动机、业务流程引擎都是干这个的。它最大的优点是可预期——每个分支都是人肉枚举过的理论上不存在“没想到”的情况只要你把场景穷举到位。但 Agent 这个场景恰恰是场景无法穷举的典型。你让 Agent 做客服用户的问题组合方式几乎是无限的你让 Agent 写代码报错信息的种类更是天量。用穷举分支的方式来应对无穷变化最直接的后果就是判断逻辑越堆越多体量彻底失控。我见过一个所谓的“智能体”核心流程里塞了四十多个 if-else 分支节点每次新增一个需求都要吭哧吭哧改半天到后面连作者自己都不知道某个分支到底会不会被触达。模型读流程的方式完全不一样。我们把流程的“骨架”写进系统提示词里把工具的说明放在模型能看到的地方然后由模型基于当前用户输入和上下文动态决定调哪个工具、用什么参数、按什么顺序执行。工程师不再控制“每一步是什么”只控制“每一步可以做什么”。这个转变的本质是从命令式编程转向声明式编程——你告诉模型“世界有哪些规则”模型自己编排“如何穿越这个世界”。1.2 大模型能力拐点指令跟随与 ReAct 为什么成为分水岭为什么以前这么做不稳现在又能做了核心变量是模型本身的指令跟随能力和推理能力已经跨过了一条看不见的线。早期模型做 ReActReasoning Acting推理加行动范式时思考过程经常跑偏。你说“请一步一步分析”它真就分五步但这五步的逻辑链前后矛盾你给它四个工具它偏要去幻想一个第五个工具出来。这就像让一个实习生独立做项目他连需求都理解不到位怎么可能做出正确决策。但以当前主流模型的能力来看只要系统提示词写得足够清晰、工具定义足够准确模型在多数场景下能够稳定地产出合理的工具调用序列并且能在失败后自行纠错。这个能力拐点的出现让“模型主导控制”第一次在工程上有了可行性。它不再是一个学术构想而是一个可以考虑上生产的架构方案。当然这并不意味着我们完全躺平把一切交给模型。恰恰相反控制权回撤是一个有策略、有方法、有护栏的工程过程需要在架构、提示词、评估、安全四个维度同时调整。下面我把这四个维度逐一拆开讲。2. 三个核心驱动力为什么模型端控制更划算控制权回撤不是一次纯粹的技术理想主义背后有非常实在的驱动力。搞清楚这些驱动力你就知道在架构设计时该往哪个方向用力。2.1 上下文工程取代状态机过去 Agent 系统特别喜欢引入状态管理用 status 字段标记当前处于哪个阶段然后根据 status 走对应的 handler。这个设计的初衷是防止 Agent 乱跑但代价是状态与状态之间的转换逻辑必须全部预先定义否则跨状态流转就断了。模型主导的模式直接绕开了这块硬骨头。模型的“状态”天然存在于上下文窗口里它自己会根据前文内容理解当前进展到了哪一步。你要做的不是设计 status 枚举而是设计上下文的结构和信息密度历史消息保留多少轮、每次工具调用的结果要不要压缩、用户的核心目标要不要单独提炼成一行置顶。这实际上是把离散的状态机压平成了一个连续的上下文流。你可能会问这么干靠谱吗模型真的能自己记住进行到哪一步了吗实测下来的答案是只要你的上下文足够清晰模型在大部分场景下的“记忆能力”比人肉维护的状态机要可靠得多因为它不只是记住了一个状态码而是记住了整个推理路径。中间某一环节出错了它还能顺着上下文往回找原因这在传统状态机里是不可能实现的。2.2 工具调用的语义化演进第二驱动力来自工具层的质变。早期 Agent 的“工具”形态很死板大多是 REST API 加一段晦涩的参数说明。模型看到工具列表跟看天书一样自然没法正确调用。现在的工具定义已经越来越讲究语义化。一个定义良好的工具应该包含这个工具到底是干什么的description 要写人话、输入参数分别代表什么含义不能只有类型没有解释、有哪些典型的调用场景最好附一两个示例。这相当于把工具说明从“程序员版 API 文档”改写成了“给实习生的操作手册”。工具定义质量的提升直接拉高了模型独立决策的上限。当模型能看懂每个工具是在干什么、什么时候该用、什么时候不该用你就不需要再在外层套一层 if-else 来做工具选择的兜底了。我们团队里有个经验值工具语义化每提升一个台阶模型自主决策的准确率就能显著提高一截。这比你在外层堆一堆校验逻辑划算得多因为前者是让模型自己变得更强后者只是在伤口上贴创可贴。2.3 反馈闭环成为模型能力的“配置项”第三个驱动力比较隐蔽但极其关键工程上开始把“反馈闭环”作为系统设计的一等公民。什么叫反馈闭环Agent 调用工具之后系统会返回一个结果这个结果必然分两类——成功或失败。传统状态机模式里失败就意味着走异常分支报错、重试、退出。但模型主导的模式不一样失败的结果会被当作新的上下文喂回给模型让模型基于失败信息分析原因、调整参数、重新尝试。这就像人做菜盐放多了怎么办加水、加糖、或者下次少放盐——你得先尝一口才知道怎么调整。把反馈闭环做成配置项的意思是你可以在系统里设定“最大重试次数”“什么类型的错误允许重试”“什么类型必须停下请示人类”等策略但具体的纠错动作由模型自己决定。从工程角度看这就把错误处理的复杂度从“穷举所有异常路径”降到了“定义异常策略边界”实现成本完全不是一个量级。3. 实操如何把 Agent 控制权顺利移交到模型手里讲完了理论直接上干货。这一节我们走一遍完整的实操流程从骨架设计到工具改造再到护栏搭建每一步都能落到代码上。3.1 第一步最小模型主导 Agent 的骨架设计先说骨架。模型主导的 Agent 代码结构比传统状态机要简单得多核心就三层上下文组装层把系统提示词、历史消息、工具调用记录拼装成模型输入模型调用循环调用模型解析输出判断是继续执行工具还是回复用户工具执行层根据模型的 tool call 执行对应函数并返回结果我给你们一个精简的可运行的循环示意用伪 Python 写def run_agent(user_input, system_prompt, tools): messages [{role: system, content: system_prompt}] messages.append({role: user, content: user_input}) while True: response call_llm(messages, tools) if response.is_tool_call(): # 模型决定调用工具 for tool_call in response.tool_calls: result execute_tool(tool_call.name, tool_call.arguments) messages.append({ role: tool, tool_call_id: tool_call.id, content: result }) # 继续循环把工具结果还给模型 continue else: # 模型认为任务已完成输出最终回复 return response.content这个循环是整个模型主导 Agent 的最小骨架。注意几个关键点call_llm每次传入完整的 messages 列表让模型看到全部历史这是它做决策的基础。工具结果用 role 区分开不要混在普通消息里。当前主流模型 API 都支持 tool role 的规范格式照着做即可。循环必须设置最大次数比如 8 次防止模型陷入死循环成本失控。这个骨架看起来简单但它真正体现了“控制权在模型手里”——循环继续还是终止完全由模型输出决定。工程师只做一件事设定资源的边界比如最大轮数、超时时间、单轮 token 预算。这就是规则和自由的分界。3.2 第二步工具层的语义化改造骨架搭好之后下一步就是把你现有的函数/API 包装成模型能看懂的“工具”。这里我强烈推荐使用模型的原生 tool calling 格式来定义而不是在提示词里用纯文本描述。原生格式能让模型更稳定地输出结构化参数同时减少解析错误。一个经验合格的工具定义大概长这样{ type: function, function: { name: search_flights, description: 搜索符合条件的航班。当用户提到出发地、目的地、出行日期时使用此工具如果用户没有明确日期默认查未来7天内的航班。, parameters: { type: object, properties: { departure: { type: string, description: 出发城市或机场三字码如北京或PEK }, arrival: { type: string, description: 目的城市或机场三字码如上海或SHA }, date: { type: string, description: 出发日期格式YYYY-MM-DD默认从明天开始 } }, required: [departure, arrival] } } }这里有几个容易踩的坑description 一定要写触发条件。模型会根据 description 决定“要不要用这个工具”所以你要明确告诉它什么情况下该调用它。我见过很多写得太泛的定义导致模型把“查天气”的工具用在“推荐穿什么衣服”的问题上。参数描述要写出默认行为。比如 date 不填怎么办你要在 description 里写清楚模型才能合理推断。不要过度设计必填参数。required 的字段越多模型调用工具的失败率越高。能让模型自己按需填充的可选字段就尽量做成可选。3.3 第三步上下文编排与预算控制模型主导模式下上下文就是 Agent 的“记忆”而记忆的质量直接决定了决策质量。实操中我主要做三件事第一浓缩用户目标。把用户的原始诉求在首次进入循环前用一行话总结出来并固定在上下文的开头。这样做的好处是即使中间工具调用结果很混乱模型始终能锚定用户的真实意图。实现上可以自己写个压缩 prompt也可以用小模型做摘要。第二做工具结果的长短截断。如果工具返回的内容很长比如数据库查询结果几千行直接全量塞给模型会挤占上下文窗口而且那些无关信息反而会干扰判断。我常用的策略是默认截断到 1500 字符以内并在结果前加一句摘要。如果模型后续需要更完整的数据它会再次调用工具获取这就是模型自主决策的好处——不需要你人为判断该给多少数据模型自己会按需索取。第三设置上下文预算上限。我一般会监控每一次调用的 token 消耗设定一个阈值比如总上下文达到 2 万 token 后开始裁剪历史消息。裁剪策略是保留第一轮 user 输入和最近两轮对话中间的对话压缩成摘要。这个“保留框架 保留最近 压缩中间”的思路在长任务场景下非常管用。3.4 第四步设置评估护栏没有评估就别谈放权把控制权交给模型不等于放任不管你必须有手段知道模型干得好不好。评估体系不是可选项而是放权的前提条件。我们团队目前用一套比较轻量的评估方案分三层单步评估tool call level模型每次调用工具后检查这次调用的参数是否合理、选择的工具是否正确。这个可以通过规则做部分覆盖比如参数类型、取值范围也可以用小模型做即时打分。任务级评估task level整个 Agent 会话结束后对“最终答复是否解决了用户问题”打分。这个直接让一个大模型来评把对话记录和工具调用记录整体丢给它输出结构化评分。回归评估regression level把历史测试集固定下来每次系统改动提示词变化、工具定义变化、模型版本升级都跑一遍对比通过率。这一步是为了防止模型能力提升或提示词微调时出现“修了一个问题、引发三个新问题”的灾难。评估集不用一开始就做得很大先搞 30 到 50 条有代表性的 case 跑起来后面持续扩充。相比没有评估的盲目迭代这套体系能在放权过程中给到足够的安全感。4. 常见问题与排查技巧实录模型主导的 Agent 跑起来之后你一定会遇到下面这些问题。我把踩过的坑和排查思路整理出来按频率从高到低排了个序。4.1 模型输出格式不稳定解析直接报了 JSON Error这是最常遇到的问题。即使模型 API 声明返回结构化 tool call偶尔也会有格式错乱的情况。排查顺序如下先检查是不是上下文太长导致模型注意力漂移。实测下来当上下文压缩不充分时模型更容易在格式上翻车。先试试裁剪历史消息问题经常就消失了。再检查工具定义是不是太多了。单次请求同时暴露超过 10 个工具给模型出错的概率会显著上升。把不常用的工具砍掉或分组懒加载。最后才是考虑解析容错。在解析层做一层的错误兜底比如提取文本块中第一个合法的 JSON 片段作为候选。但兜底是最后的办法别把兜底当主路径。4.2 Agent 陷入死循环反反复复调用同一个工具模型在遇到工具结果不理想时可能会重复尝试同样参数的调用形成死循环。这通常有两个原因工具结果里没有足够的新信息来帮助模型调整策略。此时你需要在返回给模型的工具结果中带上“错误原因分析”或“建议调整方向”。光把错误堆给模型模型只能原地重试。系统提示词里缺少“若连续两次调用同一工具且参数相似应立即停下向用户说明当前困难并请求指引”的指令。把这类止损规则显式写进提示词里能大幅减少死循环。另外别忘了代码层面的硬护栏最大循环次数要设单次执行总时间要设费用上限要设。模型发疯是必然事件护栏是为了让疯的代价可控而不是指望它永不发疯。4.3 工具调用幻觉模型调用了一个根本不存在或不该调用的工具这个问题在模型版本更新后会突然爆发。之前跑得好好的 Agent换了个新模型后突然开始频繁调用错误工具。原因大概率是新模型的先验偏好和老模型不同它可能对工具的描述理解方式发生偏移。排查动作分两步第一步用回归评估集快速对比旧模型和新模型的工具选择准确率确认是模型行为漂移。第二步针对出错的 case调整工具 description 的表述。有时候只是改一个措辞比如把“查询订单”改成“当用户询问订单状态或物流信息时调用此工具获取订单详情”模型就恢复正常了。记住工具描述是给模型看的需求文档不是给人看的 API 注释要用模型能理解的语言写。4.4 安全与权限边界模型自主执行高风险操作这是放权过程中最敏感也最不能省的一环。我的原则是分级授权关键动作人工确认。实操上先把所有工具按风险等级分类风险等级操作类型执行策略低搜索、查询、读取、计算模型自主执行无需干预中生成草稿、持久化写入、非关键配置更新模型可执行但要求执行后向用户说明高删除、转账、发布、API 密钥操作、批量修改模型只能生成“待执行操作计划”必须经用户确认后由程序层面执行落地上在工具执行层拦一道闸高风险工具直接绑定到一个人工确认函数上。模型调用时先返回一个确认请求给用户用户点了“同意”才真正执行。这个设计既保护了用户利益也让模型在大多数场景下依然享有独立行动的自由两全其美。4.5 成本不可控token 消耗比预期高出几个量级模型主导的 Agent 天然比固定流程要烧 token因为它每次都会带完整上下文、反复多次调用模型。控制成本的核心思路是选择性地使用不同大小的模型整体规划用强模型拆解任务、调用工具的主循环用能力最强的模型保证决策质量。局部总结用小模型历史压缩、工具结果摘要、单步评估这些不用太强的推理能力用小模型跑就行成本差好几倍。开启结果缓存如果同一个工具结果在短时间内被多次请求直接在应用层做缓存不要每次都去打真实 API。成本不是放权的反对理由放权之后你省下的开发调试时间折算成人力成本往往远超多花的 token 钱。关键是别让 token 浪费在上述那些无意义的重试和冗余上下文上。5. 放到更长的时间轴上看模型主导 Agent 的未来空间聊回最开始的问题控制权为什么正在回到模型手里我的判断是这不是一场技术的倒退而是 Agent 架构进化到了一个新阶段的标志。当模型的能力达到一定水位之后工程师的角色会从“流程设计者”退后一步变成“规则制定者和资源管理者”把真正的执行判断空间让给模型。这有点像从“手写汇编语言”进化到“用高级语言开发”你把底层寄存器的控制权交了出去换来的是开发效率和系统复杂度的质变。但我不是说要放弃所有流程控制。成熟的做法是找到一个合理的分工方式凡是稳定不变的部分用确定性代码实现比如数据校验、权限校验、鉴权逻辑、基础设施调用。凡是灵活应变的部分用模型自主决策实现比如任务拆解、工具选择、结果分析、错误恢复。凡是高风险、不可逆的部分一律加入人工确认环节而不是单纯信任模型的判断。这个分工模式如果真的铺开不只是 Agent 开发本身还会连带影响几个方向Agent 评估体系会从学术研究变成工程基础设施工具生态会从“人用工具”逐渐分化出“模型优先工具”——也就是专门的 MCP 服务它们的设计目标不是给人类用的而是为模型的自主调用而生的Agent 安全防护也会变成一个更独立、更细的专项领域。我个人在实际操作中的体会是不要等到模型能力“完美”了才做控制权迁移因为那一天永远不会来。在能力还存在缺口的时候用架构、护栏、评估去补位一边放权一边兜底这个动态调整的过程才是做 Agent 最有趣、也最有价值的地方。最后分享一个我一直在用的小技巧给 Agent 写系统提示词时不要把它当“指令列表”来写试着把它当“一份给聪明新同事的入职手册”来写。入职手册里你不会一条条命令他“第一步做什么、第二步做什么”你会告诉他目标是什么、边界在哪里、遇到问题可以找谁、什么红线不能碰。当你把提示词写到这个程度模型主导的 Agent 往往能给你出乎意料的惊喜。这既是技术的修炼也是一次对“人机关系”理解的升级。 Agent控制权转移：从流程编排到模型自主决策的架构革命
1. 控制权转移Agent 架构正在经历的一次身份重构最近圈里聊 Agent 的时候风向明显变了。一年前大家问得最多的是“用哪个 Agent 框架”“怎么编排多智能体”“工作流节点怎么连”现在挂在嘴边的变成了另一句话——“能不能让模型自己决定下一步干什么”这个转变非常微妙但影响深远。它本质上是在回答一个核心问题在 Agent 系统里到底谁说了算是工程师预设的流程逻辑还是模型基于上下文做出的动态判断我把这个趋势叫做“控制权回撤”。注意我用的是“回”字因为最早做 Agent 的时候大家就是靠模型一句话一句话地生成动作的。后来发现纯靠模型太飘不稳定、不可控于是开始上硬编码流程、状态机、工作流编排把模型的自由度牢牢圈起来。但圈到极致之后大家又发现另一个问题流程写死之后Agent 变成了一个只会按剧本走戏的演员稍微遇到点剧本外的情况就卡壳。于是控制权又开始往模型手里移动。这就像带孩子一开始放任自流结果闯了祸后来管得太严发现孩子完全失去了应变能力现在大家正在摸索的是那种“关键规则我来定具体怎么做事你说了算”的边界感。这个平衡点在哪正是当前 Agent 开发中最值得深耕的方向。1.1 从“人写流程”到“模型读流程”传统的 Agent 设计逻辑是自上而下的工程师画一张流程图A 节点做什么、B 节点做什么、如果出现条件 X 就跳转到 C 节点。这套思路在软件工程里非常成熟状态机、有限自动机、业务流程引擎都是干这个的。它最大的优点是可预期——每个分支都是人肉枚举过的理论上不存在“没想到”的情况只要你把场景穷举到位。但 Agent 这个场景恰恰是场景无法穷举的典型。你让 Agent 做客服用户的问题组合方式几乎是无限的你让 Agent 写代码报错信息的种类更是天量。用穷举分支的方式来应对无穷变化最直接的后果就是判断逻辑越堆越多体量彻底失控。我见过一个所谓的“智能体”核心流程里塞了四十多个 if-else 分支节点每次新增一个需求都要吭哧吭哧改半天到后面连作者自己都不知道某个分支到底会不会被触达。模型读流程的方式完全不一样。我们把流程的“骨架”写进系统提示词里把工具的说明放在模型能看到的地方然后由模型基于当前用户输入和上下文动态决定调哪个工具、用什么参数、按什么顺序执行。工程师不再控制“每一步是什么”只控制“每一步可以做什么”。这个转变的本质是从命令式编程转向声明式编程——你告诉模型“世界有哪些规则”模型自己编排“如何穿越这个世界”。1.2 大模型能力拐点指令跟随与 ReAct 为什么成为分水岭为什么以前这么做不稳现在又能做了核心变量是模型本身的指令跟随能力和推理能力已经跨过了一条看不见的线。早期模型做 ReActReasoning Acting推理加行动范式时思考过程经常跑偏。你说“请一步一步分析”它真就分五步但这五步的逻辑链前后矛盾你给它四个工具它偏要去幻想一个第五个工具出来。这就像让一个实习生独立做项目他连需求都理解不到位怎么可能做出正确决策。但以当前主流模型的能力来看只要系统提示词写得足够清晰、工具定义足够准确模型在多数场景下能够稳定地产出合理的工具调用序列并且能在失败后自行纠错。这个能力拐点的出现让“模型主导控制”第一次在工程上有了可行性。它不再是一个学术构想而是一个可以考虑上生产的架构方案。当然这并不意味着我们完全躺平把一切交给模型。恰恰相反控制权回撤是一个有策略、有方法、有护栏的工程过程需要在架构、提示词、评估、安全四个维度同时调整。下面我把这四个维度逐一拆开讲。2. 三个核心驱动力为什么模型端控制更划算控制权回撤不是一次纯粹的技术理想主义背后有非常实在的驱动力。搞清楚这些驱动力你就知道在架构设计时该往哪个方向用力。2.1 上下文工程取代状态机过去 Agent 系统特别喜欢引入状态管理用 status 字段标记当前处于哪个阶段然后根据 status 走对应的 handler。这个设计的初衷是防止 Agent 乱跑但代价是状态与状态之间的转换逻辑必须全部预先定义否则跨状态流转就断了。模型主导的模式直接绕开了这块硬骨头。模型的“状态”天然存在于上下文窗口里它自己会根据前文内容理解当前进展到了哪一步。你要做的不是设计 status 枚举而是设计上下文的结构和信息密度历史消息保留多少轮、每次工具调用的结果要不要压缩、用户的核心目标要不要单独提炼成一行置顶。这实际上是把离散的状态机压平成了一个连续的上下文流。你可能会问这么干靠谱吗模型真的能自己记住进行到哪一步了吗实测下来的答案是只要你的上下文足够清晰模型在大部分场景下的“记忆能力”比人肉维护的状态机要可靠得多因为它不只是记住了一个状态码而是记住了整个推理路径。中间某一环节出错了它还能顺着上下文往回找原因这在传统状态机里是不可能实现的。2.2 工具调用的语义化演进第二驱动力来自工具层的质变。早期 Agent 的“工具”形态很死板大多是 REST API 加一段晦涩的参数说明。模型看到工具列表跟看天书一样自然没法正确调用。现在的工具定义已经越来越讲究语义化。一个定义良好的工具应该包含这个工具到底是干什么的description 要写人话、输入参数分别代表什么含义不能只有类型没有解释、有哪些典型的调用场景最好附一两个示例。这相当于把工具说明从“程序员版 API 文档”改写成了“给实习生的操作手册”。工具定义质量的提升直接拉高了模型独立决策的上限。当模型能看懂每个工具是在干什么、什么时候该用、什么时候不该用你就不需要再在外层套一层 if-else 来做工具选择的兜底了。我们团队里有个经验值工具语义化每提升一个台阶模型自主决策的准确率就能显著提高一截。这比你在外层堆一堆校验逻辑划算得多因为前者是让模型自己变得更强后者只是在伤口上贴创可贴。2.3 反馈闭环成为模型能力的“配置项”第三个驱动力比较隐蔽但极其关键工程上开始把“反馈闭环”作为系统设计的一等公民。什么叫反馈闭环Agent 调用工具之后系统会返回一个结果这个结果必然分两类——成功或失败。传统状态机模式里失败就意味着走异常分支报错、重试、退出。但模型主导的模式不一样失败的结果会被当作新的上下文喂回给模型让模型基于失败信息分析原因、调整参数、重新尝试。这就像人做菜盐放多了怎么办加水、加糖、或者下次少放盐——你得先尝一口才知道怎么调整。把反馈闭环做成配置项的意思是你可以在系统里设定“最大重试次数”“什么类型的错误允许重试”“什么类型必须停下请示人类”等策略但具体的纠错动作由模型自己决定。从工程角度看这就把错误处理的复杂度从“穷举所有异常路径”降到了“定义异常策略边界”实现成本完全不是一个量级。3. 实操如何把 Agent 控制权顺利移交到模型手里讲完了理论直接上干货。这一节我们走一遍完整的实操流程从骨架设计到工具改造再到护栏搭建每一步都能落到代码上。3.1 第一步最小模型主导 Agent 的骨架设计先说骨架。模型主导的 Agent 代码结构比传统状态机要简单得多核心就三层上下文组装层把系统提示词、历史消息、工具调用记录拼装成模型输入模型调用循环调用模型解析输出判断是继续执行工具还是回复用户工具执行层根据模型的 tool call 执行对应函数并返回结果我给你们一个精简的可运行的循环示意用伪 Python 写def run_agent(user_input, system_prompt, tools): messages [{role: system, content: system_prompt}] messages.append({role: user, content: user_input}) while True: response call_llm(messages, tools) if response.is_tool_call(): # 模型决定调用工具 for tool_call in response.tool_calls: result execute_tool(tool_call.name, tool_call.arguments) messages.append({ role: tool, tool_call_id: tool_call.id, content: result }) # 继续循环把工具结果还给模型 continue else: # 模型认为任务已完成输出最终回复 return response.content这个循环是整个模型主导 Agent 的最小骨架。注意几个关键点call_llm每次传入完整的 messages 列表让模型看到全部历史这是它做决策的基础。工具结果用 role 区分开不要混在普通消息里。当前主流模型 API 都支持 tool role 的规范格式照着做即可。循环必须设置最大次数比如 8 次防止模型陷入死循环成本失控。这个骨架看起来简单但它真正体现了“控制权在模型手里”——循环继续还是终止完全由模型输出决定。工程师只做一件事设定资源的边界比如最大轮数、超时时间、单轮 token 预算。这就是规则和自由的分界。3.2 第二步工具层的语义化改造骨架搭好之后下一步就是把你现有的函数/API 包装成模型能看懂的“工具”。这里我强烈推荐使用模型的原生 tool calling 格式来定义而不是在提示词里用纯文本描述。原生格式能让模型更稳定地输出结构化参数同时减少解析错误。一个经验合格的工具定义大概长这样{ type: function, function: { name: search_flights, description: 搜索符合条件的航班。当用户提到出发地、目的地、出行日期时使用此工具如果用户没有明确日期默认查未来7天内的航班。, parameters: { type: object, properties: { departure: { type: string, description: 出发城市或机场三字码如北京或PEK }, arrival: { type: string, description: 目的城市或机场三字码如上海或SHA }, date: { type: string, description: 出发日期格式YYYY-MM-DD默认从明天开始 } }, required: [departure, arrival] } } }这里有几个容易踩的坑description 一定要写触发条件。模型会根据 description 决定“要不要用这个工具”所以你要明确告诉它什么情况下该调用它。我见过很多写得太泛的定义导致模型把“查天气”的工具用在“推荐穿什么衣服”的问题上。参数描述要写出默认行为。比如 date 不填怎么办你要在 description 里写清楚模型才能合理推断。不要过度设计必填参数。required 的字段越多模型调用工具的失败率越高。能让模型自己按需填充的可选字段就尽量做成可选。3.3 第三步上下文编排与预算控制模型主导模式下上下文就是 Agent 的“记忆”而记忆的质量直接决定了决策质量。实操中我主要做三件事第一浓缩用户目标。把用户的原始诉求在首次进入循环前用一行话总结出来并固定在上下文的开头。这样做的好处是即使中间工具调用结果很混乱模型始终能锚定用户的真实意图。实现上可以自己写个压缩 prompt也可以用小模型做摘要。第二做工具结果的长短截断。如果工具返回的内容很长比如数据库查询结果几千行直接全量塞给模型会挤占上下文窗口而且那些无关信息反而会干扰判断。我常用的策略是默认截断到 1500 字符以内并在结果前加一句摘要。如果模型后续需要更完整的数据它会再次调用工具获取这就是模型自主决策的好处——不需要你人为判断该给多少数据模型自己会按需索取。第三设置上下文预算上限。我一般会监控每一次调用的 token 消耗设定一个阈值比如总上下文达到 2 万 token 后开始裁剪历史消息。裁剪策略是保留第一轮 user 输入和最近两轮对话中间的对话压缩成摘要。这个“保留框架 保留最近 压缩中间”的思路在长任务场景下非常管用。3.4 第四步设置评估护栏没有评估就别谈放权把控制权交给模型不等于放任不管你必须有手段知道模型干得好不好。评估体系不是可选项而是放权的前提条件。我们团队目前用一套比较轻量的评估方案分三层单步评估tool call level模型每次调用工具后检查这次调用的参数是否合理、选择的工具是否正确。这个可以通过规则做部分覆盖比如参数类型、取值范围也可以用小模型做即时打分。任务级评估task level整个 Agent 会话结束后对“最终答复是否解决了用户问题”打分。这个直接让一个大模型来评把对话记录和工具调用记录整体丢给它输出结构化评分。回归评估regression level把历史测试集固定下来每次系统改动提示词变化、工具定义变化、模型版本升级都跑一遍对比通过率。这一步是为了防止模型能力提升或提示词微调时出现“修了一个问题、引发三个新问题”的灾难。评估集不用一开始就做得很大先搞 30 到 50 条有代表性的 case 跑起来后面持续扩充。相比没有评估的盲目迭代这套体系能在放权过程中给到足够的安全感。4. 常见问题与排查技巧实录模型主导的 Agent 跑起来之后你一定会遇到下面这些问题。我把踩过的坑和排查思路整理出来按频率从高到低排了个序。4.1 模型输出格式不稳定解析直接报了 JSON Error这是最常遇到的问题。即使模型 API 声明返回结构化 tool call偶尔也会有格式错乱的情况。排查顺序如下先检查是不是上下文太长导致模型注意力漂移。实测下来当上下文压缩不充分时模型更容易在格式上翻车。先试试裁剪历史消息问题经常就消失了。再检查工具定义是不是太多了。单次请求同时暴露超过 10 个工具给模型出错的概率会显著上升。把不常用的工具砍掉或分组懒加载。最后才是考虑解析容错。在解析层做一层的错误兜底比如提取文本块中第一个合法的 JSON 片段作为候选。但兜底是最后的办法别把兜底当主路径。4.2 Agent 陷入死循环反反复复调用同一个工具模型在遇到工具结果不理想时可能会重复尝试同样参数的调用形成死循环。这通常有两个原因工具结果里没有足够的新信息来帮助模型调整策略。此时你需要在返回给模型的工具结果中带上“错误原因分析”或“建议调整方向”。光把错误堆给模型模型只能原地重试。系统提示词里缺少“若连续两次调用同一工具且参数相似应立即停下向用户说明当前困难并请求指引”的指令。把这类止损规则显式写进提示词里能大幅减少死循环。另外别忘了代码层面的硬护栏最大循环次数要设单次执行总时间要设费用上限要设。模型发疯是必然事件护栏是为了让疯的代价可控而不是指望它永不发疯。4.3 工具调用幻觉模型调用了一个根本不存在或不该调用的工具这个问题在模型版本更新后会突然爆发。之前跑得好好的 Agent换了个新模型后突然开始频繁调用错误工具。原因大概率是新模型的先验偏好和老模型不同它可能对工具的描述理解方式发生偏移。排查动作分两步第一步用回归评估集快速对比旧模型和新模型的工具选择准确率确认是模型行为漂移。第二步针对出错的 case调整工具 description 的表述。有时候只是改一个措辞比如把“查询订单”改成“当用户询问订单状态或物流信息时调用此工具获取订单详情”模型就恢复正常了。记住工具描述是给模型看的需求文档不是给人看的 API 注释要用模型能理解的语言写。4.4 安全与权限边界模型自主执行高风险操作这是放权过程中最敏感也最不能省的一环。我的原则是分级授权关键动作人工确认。实操上先把所有工具按风险等级分类风险等级操作类型执行策略低搜索、查询、读取、计算模型自主执行无需干预中生成草稿、持久化写入、非关键配置更新模型可执行但要求执行后向用户说明高删除、转账、发布、API 密钥操作、批量修改模型只能生成“待执行操作计划”必须经用户确认后由程序层面执行落地上在工具执行层拦一道闸高风险工具直接绑定到一个人工确认函数上。模型调用时先返回一个确认请求给用户用户点了“同意”才真正执行。这个设计既保护了用户利益也让模型在大多数场景下依然享有独立行动的自由两全其美。4.5 成本不可控token 消耗比预期高出几个量级模型主导的 Agent 天然比固定流程要烧 token因为它每次都会带完整上下文、反复多次调用模型。控制成本的核心思路是选择性地使用不同大小的模型整体规划用强模型拆解任务、调用工具的主循环用能力最强的模型保证决策质量。局部总结用小模型历史压缩、工具结果摘要、单步评估这些不用太强的推理能力用小模型跑就行成本差好几倍。开启结果缓存如果同一个工具结果在短时间内被多次请求直接在应用层做缓存不要每次都去打真实 API。成本不是放权的反对理由放权之后你省下的开发调试时间折算成人力成本往往远超多花的 token 钱。关键是别让 token 浪费在上述那些无意义的重试和冗余上下文上。5. 放到更长的时间轴上看模型主导 Agent 的未来空间聊回最开始的问题控制权为什么正在回到模型手里我的判断是这不是一场技术的倒退而是 Agent 架构进化到了一个新阶段的标志。当模型的能力达到一定水位之后工程师的角色会从“流程设计者”退后一步变成“规则制定者和资源管理者”把真正的执行判断空间让给模型。这有点像从“手写汇编语言”进化到“用高级语言开发”你把底层寄存器的控制权交了出去换来的是开发效率和系统复杂度的质变。但我不是说要放弃所有流程控制。成熟的做法是找到一个合理的分工方式凡是稳定不变的部分用确定性代码实现比如数据校验、权限校验、鉴权逻辑、基础设施调用。凡是灵活应变的部分用模型自主决策实现比如任务拆解、工具选择、结果分析、错误恢复。凡是高风险、不可逆的部分一律加入人工确认环节而不是单纯信任模型的判断。这个分工模式如果真的铺开不只是 Agent 开发本身还会连带影响几个方向Agent 评估体系会从学术研究变成工程基础设施工具生态会从“人用工具”逐渐分化出“模型优先工具”——也就是专门的 MCP 服务它们的设计目标不是给人类用的而是为模型的自主调用而生的Agent 安全防护也会变成一个更独立、更细的专项领域。我个人在实际操作中的体会是不要等到模型能力“完美”了才做控制权迁移因为那一天永远不会来。在能力还存在缺口的时候用架构、护栏、评估去补位一边放权一边兜底这个动态调整的过程才是做 Agent 最有趣、也最有价值的地方。最后分享一个我一直在用的小技巧给 Agent 写系统提示词时不要把它当“指令列表”来写试着把它当“一份给聪明新同事的入职手册”来写。入职手册里你不会一条条命令他“第一步做什么、第二步做什么”你会告诉他目标是什么、边界在哪里、遇到问题可以找谁、什么红线不能碰。当你把提示词写到这个程度模型主导的 Agent 往往能给你出乎意料的惊喜。这既是技术的修炼也是一次对“人机关系”理解的升级。