说个我最近比较有共鸣的判断Agent 的能力可以随便耦合但它的执行必须标准化。这话不是我拍脑袋琢磨出来的而是最近读了一篇专门讨论 Agent 生产落地的论文之后再对照自己做过的一堆项目越品越觉得论文把很多团队踩过的坑提前画出来了。这篇文章不打算干巴巴复述论文而是把它背后的几个核心问题拆开讲为什么生产环境里的 Agent 和论文里的 Demo 完全是两回事、执行标准化到底要标准哪些东西、能力耦合的边界在哪里、以及真正出了问题怎么排查。我会把论文的实验逻辑和实际操作经验放在一起讲适合正在做 Agent 应用、或者正准备把 Agent 从原型推到生产环境的技术同学参考。先说结论放在前面如果你只记住了论文里的一句话那应该是“框架负责耦合能力流程负责标准化执行”。这句话值得贴在工位上。1. 那篇论文到底讲了个什么事1.1 三种架构的对比实验论文的实验设计其实非常朴素没有用什么花哨的 benchmark反而挑了三个偏真实工作流的任务集工单处理、文档分析、工具链调用。每个任务集里都存在多步骤的依赖关系比如先查用户信息再判断问题类型然后检索知识库最后生成回复并且创建记录。任务难度还做了分层简单任务步骤少复杂任务步骤多且存在分支。论文把同一个底座模型分别跑在三套架构上架构 A完全自由型 Agent。一个 Agent 拥有全部工具由模型自行决定调用顺序和调用时机不做任何流程约束。架构 B半约束型 Agent。系统提供一套流程模板作为参考模型可以偏离模板但偏离时会收到提示。架构 C全标准化 Agent。执行链路被拆成有限状态机解析、计划、执行、校验、输出每个节点只允许特定的工具和特定的输出格式。结果很有冲击力在简单任务上三套架构差距不大自由型甚至偶尔表现更好但任务一复杂差距立刻拉开。论文里的数据大致落在这样一个区间架构调用方式简单任务成功率复杂任务成功率A 自由调用模型自己决定一切84% 左右47% 左右B 模板引导有模板但允许偏离83% 左右52% 左右C 状态机约束强制按状态流转88% 左右73% 左右复杂任务上自由型和约束型的成功率差了超过二十个百分点。这个差距不是模型能力造成的因为底座模型是同一个。模型一样、工具一样唯一的变量就是执行层有没有被标准化。1.2 为什么“不自由”反而成功率高这个结论多少有点反直觉毕竟平时开发 Agent 的时候大家都希望模型发挥更大的自主性觉得自由度高就是智能。论文里给出的解释拆开看其实指向三个非常现实的问题。第一个是误差累计。一个复杂任务要拆成十几个步骤每步都有概率出现微小偏差比如选中了次优工具、漏了一个参数、或者对中间结果的理解出现了一点偏移。自由型架构下模型每一步都在“自由发挥”每步的偏差会慢慢累积越到后面越容易滚成一个大错误。而状态机架构把每一步的输入输出都卡死了模型只能在有限的选择里做决策偏差被约束在一个很小的范围内。第二个是决策稳定性。模型在开放选择空间下并不总能选到最优路径。工具描述写得再清楚也架不住几十个工具摆在一起模型有时候就是会选错。而标准化架构会把“在当前状态下只有两三个合法动作”作为一个硬条件模型做选择的压力小很多选对的概率自然上去了。第三个是出错后的定位成本。自由型架构一旦任务失败你很难说清楚到底是哪一步错了。是提示词写得不到位还是工具返回的结果有问题还是模型自己在某个环节开小差所有环节搅在一起排查成本很高。而状态机架构天然把流程切成了节点每个节点有独立的输入输出和日志失败发生在哪个节点一看便知。这里有个很重要的理解架构 C 并不是把 Agent 的“能力”阉割了。模型依然负责理解意图、做计划、组织语言、调用工具能力上是完整的。标准化的只是执行层的外在表现。这就是论文标题那句话的由来能力可以耦合执行必须标准化。2. 生产环境里的 Agent 到底乱在哪2.1 我见过或者踩过的几类典型事故论文里的实验设计对我来说很有画面感因为我在实际项目里见过太多对应的问题了。举几个真实场景。第一个案例是工具调用竞态。有个做内容生成的 Agent需求是先调用图片生成接口等图片返回后再调用排版接口。模型在自由模式下经常“急性子”图片接口还没返回完成它就已经开始调用排版接口结果排版接口拿到的是空地址整条流程直接失败。如果执行层有明确的状态控制要求必须收到图片接口的成功回执之后才允许进入下一个状态这类问题根本不会发生。第二个案例是上下文丢失。做过复杂任务 Agent 的应该都有体会模型一旦生成长文本或者多轮推理前面得出的中间结论可能被“挤”出上下文窗口。有个文档处理 Agent在处理几十页的 PDF 时前面几步已经判断出文档类型和关键字段但在后续步骤里它又忘记了这些结论重新开始分析导致处理结果前后矛盾。问题本质是中间状态没有落库全都依赖模型自己的记忆而模型记忆本来就是不可靠的。第三个案例是输出格式漂移。同一套提示词模型有时候输出标准 JSON有时候输出带 Markdown 代码块的 JSON有时候在 JSON 前后夹带几句解释。下游解析器只认 JSON于是出现间歇性失败。这种问题在自由文本输出模式下很难根除如果你要求模型必须通过工具调用而不是裸文本输出结构化结果稳定性会好很多。2.2 论文环境与生产环境的思维差异很多刚接触 Agent 的同学会困惑论文里的 Agent 看起来都挺聪明为什么我一放到生产环境就各种翻车这里面的核心差异其实是“能不能做”和“能不能一直做”的区别。维度论文 / 实验环境生产环境成功定义任务平均完成度允许部分失败可重复的完成率低方差失败率要压到很低容错能力高bad case 可以事后分析低一个严重错误可能就是线上事故可观测性可以重新跑实验边跑边加日志必须先有日志事后不能重放现场交接运维论文作者自己维护几周任何一个工程师都能接手维护迭代方式换更好的模型就行换模型要过回归测试任何变更都要有对照这个表我用过很多次每次拿给团队看都挺扎心。原因是研究者和工程师面对同一个 Agent 时默认的评价方式其实是打架的。研究视角下模型能不能处理一个没见过的复杂问题是核心工程视角下一个已经能跑的流程会不会在边界条件下突然出错才是核心。我自己以前也吃过类似的亏。第一个 Agent 项目上线前我很兴奋觉得模型很聪明各种刁钻的输入都能接得住。结果一放量开始出现各种以前测试时完全没见过的输入模型开始“自由发挥”偶尔冒出几句不可控的输出直接把下游系统搞崩。从那时候起我就下了个决心Agent 的能力可以强但每一次执行必须像流水线一样可预期。3. Agent 执行标准化到底要标准哪些事3.1 流程标准化用状态机代替自由发挥流程标准化是最底层的一层也是让 Agent 从“Demo 级”走向“生产级”最关键的一步。我的做法是把一个 Agent 任务抽象成有限状态机每个状态代表执行链路中的一个阶段状态之间的转移条件必须显式声明。常用的状态集合大致是这样RECEIVE接收原始请求完成基础解析比如识别意图、提取关键参数。PLAN任务拆解选定工具生成执行计划。EXECUTE逐项调用工具获取中间结果。VERIFY对执行结果做校验包括格式校验和业务规则校验。OUTPUT输出结构化结果或者进入转人工流程。ESCALATE失败重试或者升级给人工处理。状态机最大的好处是它天然只有有限条合法路径可以穷举验证。每一次任务执行最终都能落在少数几种结局里——成功输出、重试、升级。出问题的时候可以根据当前状态直接定位环节不需要去猜测模型刚才在想什么。设计状态机的时候有三个原则值得记住。第一状态数量宁少勿多语义要清晰不要为了追求精细拆出十几个状态那样维护成本会很高。第二状态转移条件必须显式声明不能用“如果模型觉得合适就跳转”这种话要落到具体的判断逻辑上。第三每个状态都要有超时和告警一个状态卡了超过设定时间要能自动触发告警或者进入升级流程。这里补充一个实操心得状态机并不是要把模型“圈养”起来。恰恰相反我会在 PLAN 和 EXECUTE 这两个状态里给模型留足自由度让它能自主选择工具和参数只是把选择范围从“所有工具”收敛到“当前任务域内的工具”。这种折中既保住了灵活性又避免了模型在海量工具中迷失方向。3.2 接口标准化输入输出必须带 Schema流程标准化管的是“每一步做什么”接口标准化管的是“每一步怎么传数据”。如果每个环节的输入输出格式不统一状态机再清晰也会被乱七八糟的数据冲垮。接口标准化要覆盖三层。第一层是工具接口。每个工具暴露出来的输入输出都要有严格 Schema描述里不要写模糊的话。工具描述尽量只承担单一职责一个工具只干一件事描述里明确适用场景、参数格式、返回格式、还有使用限制。比如一个知识库检索工具描述里面不要写“可以搜索任何资料”要写成“在技术支持知识库中检索与问题相关的文档仅用于技术咨询不用于订单和财务问题”。这样模型在选择工具时误判概率会低很多。第二层是模型输出接口。在真实生产项目里我不太建议让模型用自然语言直接输出全部结果除非是最终面向用户的回复。中间环节的结构化结果比如意图分类、抽取出的参数、校验结果都应该通过函数调用或者结构化生成来产出。你可以在提示词里写“必须且只能输出 JSON”但更可靠的方式是在架构层面要求模型通过 function calling 返回结构化结果让解析层直接拿到 object而不是拿文本再解析一次。第三层是数据协议。整个执行链路中的上下文传递字段名、类型、嵌套结构要全局统一。一个典型的上下文结构长这样{ task_id: task_20250101_001, state: EXECUTE, input: { raw_text: 用户反馈登录页面打不开, parsed: { intent: fault, entities: { product: app, symptom: login_failure } } }, context: { user_id: u_10001, source: customer_service }, intermediate: { knowledge_docs: [doc_01, doc_02] }, final_output: null }每个字段都有明确含义每个环节把自己产生的结果写入对应字段不覆盖不属于自己的字段。这样做还有个额外好处整条链路的输入输出都可以被打日志记录下来事后复盘非常清晰。3.3 评估标准化Agent Evals 要变成回归集聊到 Agent 评估很多人第一反应是“拿几个测试用例跑一遍看看回答准不准”。这个思路在原型阶段没问题但离生产级的要求差得很远。生产环境真正需要的是可回归、可对比、可量化的评估体系而不是一个“凭感觉还行”的主观评价。我自己做 Agent Evals 的时候一般分四步走。第一步沉淀真实样本集。把过去两三个月生产环境里遇到的真实任务收集起来按照业务场景分类大致覆盖高频场景和典型边界场景。样本量至少要有上百条太少了做不了对比。第二步定义多维指标。任务完成率当然要关注但不能只看这一个。我通常同时看步骤合规率、平均时延、单任务 token 成本、转人工比例这几个维度。步骤合规率很重要它反映的是 Agent 有没有按照标准化流程去执行而不是只看最后的输出结果对不对。第三步建立基线。用当前线上版本的 Agent 跑一遍回归集记录各项指标作为基线。之后每一次改动不管是改提示词、换模型、调工具都重新跑一遍和基线对比。第四步把评估结果和运维数据打通。线上系统每天产生大量真实执行记录把这些记录自动回流到评估集里。遇到线上事故立刻把出事的这条输入加入回归集确保以后同样的场景不会再被忽略。这套评估体系看起来麻烦但真的能救命。我团队里曾经为了一个很小的问题——把工具描述里的一个词从“获取”改成“查询”——到底有没有影响直接跑了整轮回归发现某个边角场景的成功率掉了一点五个百分点。如果没有评估体系这种细微的退化根本发现不了等线上出问题再查浪费的时间和精力会比跑回归多得多。4. 一个可抄作业的落地案例客服工单 Agent4.1 场景拆解与状态机设计前面讲了很多原则这里用一个具体的例子把它们串起来。我选的是“客服工单 Agent”因为这个场景足够通用而且天然依赖多步骤执行非常适合展示标准化怎么做。需求背景技术支持团队每天收到大量用户反馈需要 Agent 判断问题类型、检索知识库、生成解决方案必要时创建内部工单。全部通过人工处理成本太高直接让模型自由发挥又不可控所以要做成标准化执行的状态机。状态机设计如下intent意图识别区分账号问题、使用咨询、故障报修、其他。retrieve根据意图检索知识库取回相关文档。generate基于检索结果生成回复草稿。validate校验草稿是否覆盖关键信息比如是否引用了知识库来源、是否包含可执行的操作步骤。respond通过校验则输出回复校验不通过则进入 escalate。escalate转接人工客服附上当前上下文和失败原因。这个状态机和第四章抽象模型的思路一致只是针对客服场景做了瘦身。每个状态做的事情非常明确状态之间的跳转也完全确定。比如 generate 完成后直接进 validatevalidate 只有两个出口通过进 respond不通过进 escalate不存在“模型觉得差不多就继续”这种模糊情况。4.2 关键实现细节第一个细节是每个状态的输出必须结构化。以 intent 状态为例它输出的不是一句“用户遇到了登录问题”的自然语言而是一段稳定的 JSON{ category: fault, confidence: 0.92, extracted: { product: app, symptom: login_failure, os: android } }这样下游 retrieve 状态不需要再理解自然语言直接根据 category 和 extracted 字段去检索就行。第二个细节是知识库工具的描述要写得足够“窄”。一个检索工具的描述示例是这样{ name: search_knowledge_base, description: 在技术支持知识库中检索与问题相关的文档仅用于技术咨询类问题不用于订单、财务类查询。, parameters: { type: object, properties: { query: { type: string, description: 检索关键词尽量提取核心名词比如登录失败、闪退 }, top_k: { type: integer, description: 返回文档数量默认5最大10 } }, required: [query] } }第三个细节是提示词模板要围绕状态组织。generate 状态的提示词大致是这个风格你是一名技术支持助手。 当前任务状态生成回复。 用户原始反馈{raw_text} 已检索到的知识库文档{docs} 请根据以上文档生成回复要求包含具体操作步骤并在末尾标注引用来源。 输出格式严格 JSON。 {json_schema}这些细节每一项单独看都不复杂但组合在一起效果就出来了。模型发挥的空间被约束在“怎么表达”上而不是“要不要遵守流程”上。即使这次生成的回复不合格也可以明确知道是在 validate 状态被拦下来的而不是莫名其妙地在某个无规则的环节失败了。4.3 配套的可观测性配置执行标准化的另一面是可观测。如果每步执行不落日志标准化就没有意义。客服工单 Agent 上线的时候我在日志和追踪上做了三件事。第一每个任务从进入系统开始就生成一个 task_id贯穿所有状态和所有工具调用。每一条日志、每一次模型调用、每一个工具返回都带上这个 task_id。这样遇到有用户投诉“回复不对”可以直接通过 task_id 把整条执行链捞出来。第二每个状态执行时记录输入、输出、耗时、token 消耗。这些数据不仅要供排查用还能用来做成本分析和性能分析。哪个状态耗 token 最多哪个流程经常卡在哪个状态通过统计日志都能看出来。第三建立反馈闭环。客服工单 Agent 的回复发给用户之后用户的后续行为要回流。用户点了“有帮助”还是“没帮助”有没有再追加问题这些数据全部回流到评估集里。这样每一个执行结果都成为下一次迭代的养料。代码骨架其实很简单核心就是一个状态循环import enum class Step(enum.Enum): INTENT intent RETRIEVE retrieve GENERATE generate VALIDATE validate RESPOND respond ESCALATE escalate def run_agent(raw_text: str, context: dict) - dict: ctx { task_id: generate_task_id(), raw_text: raw_text, context: context, state: Step.INTENT, intermediate: {}, } while True: state ctx[state] if state Step.INTENT: ctx[intermediate][intent] classify_intent(raw_text) ctx[state] Step.RETRIEVE elif state Step.RETRIEVE: ctx[intermediate][docs] search_knowledge_base(...) ctx[state] Step.GENERATE elif state Step.GENERATE: ctx[intermediate][draft] generate_reply(...) ctx[state] Step.VALIDATE elif state Step.VALIDATE: if validate_reply(ctx[intermediate]): ctx[state] Step.RESPOND else: ctx[state] Step.ESCALATE elif state Step.RESPOND: return send_reply(ctx) else: return escalate_to_human(ctx)这段代码言简意赅真实项目里每个函数都会更复杂但骨架变不了。我最喜欢这个模式的地方在于它把 Agent 的“智能感”收敛到了若干个决策点上其余部分全部是确定性的工程逻辑。这恰恰是生产环境最需要的东西。5. 能力耦合的边界在哪里5.1 哪些能力可以放心地耦合在一起既然说“能力可以耦合”那到底哪些能力可以放心地揉在一起我的判断标准也很简单看这个能力是不是在同一任务域内、是不是遵循同样的业务约束、是不是可以被独立替换。同一任务域内的能力适合耦合。比如客服 Agent 里的意图识别、知识库检索、回复生成这三者围绕的都是“回答用户问题”这个目标领域一致数据结构也天然衔接放在一个 Agent 内部非常自然。这种情况下硬拆成多个微服务反而会因为接口调用开销而拖慢速度。可以复用的能力也适合耦合。比如记忆组件不管是长期记忆还是短期记忆它们提供服务的方式是一样的底层存储也是同一套就没有必要拆成两个 Agent 来管。再比如 RAG 的检索加重排检索完紧接着重排中间状态不外泄这种流水线式能力封装在一起更高效。耦合的核心原则是高内聚、低耦合、可替换。高内聚是让同一个领域的能力聚在一起低耦合是让不同领域之间只通过标准消息通信可替换是任何一个能力组件都可以被替换而不影响主流程。只要满足这三条能力耦合得再深也不用怕。5.2 哪些能力必须放在 Agent 外部能力耦合不是没有边界有几类能力我强烈建议永远不要放进 Agent 内部。权限控制必须外置。Agent 不能自己决定“当前用户有没有权限执行这个操作”权限判断必须是外部代码用确定性的规则完成。模型可以猜测用户意图但绝不能让模型拍板“放行”。我见过有团队让 Agent 根据用户描述动态判断打折权限结果被恶意输入绕过规则最后还是要人工介入处理。审计与溯源必须外置。Agent 的所有行为都要留痕并且这个留痕机制不能依赖 Agent 自己“想起来要记”。日志要由外部审计服务统一记录Agent 只负责执行记录是执行环境强制的。这样即使 Agent 被搞崩溃了日志还在。安全与脱敏必须外置。任何进入 Agent 的输入、任何从 Agent 出去的输出都要经过外部安全组件。脱敏、拦截、内容合规检查不能交给模型“自觉”。模型本质上是概率系统你没法保证它在高压场景下每次都做对。成本控制也必须外置。单任务的最大 token 数、最大工具调用次数、单次调用的超时时间都应该是执行环境层面的硬限制而不是提示词里的“建议”。我做过一个 Agent模型在一个错误分支里连续调用了十几次工具要不是设置了次数上限一次任务的成本就够喝一壶的了。这些能力外置之后Agent 反而更纯粹了它负责理解和产出安全、权限、成本由外围的护栏统一兜住。这个模式和“能力可以耦合执行必须标准化”是一个逻辑。5.3 多 Agent 协作同样适用这套逻辑如果你已经踩上了多 Agent 协作的坑应该会深刻理解为什么执行标准化在多 Agent 场景下更重要。很多团队一上来就搞“自由协商”让两个 Agent 直接用自然语言对话来完成任务。听起来很智能实际跑起来就像开一个没人控场的在线会议聊着聊着就跑题了。生产环境下的多 Agent 协作更接近微服务之间的通信协议而不是人与人之间的聊天。我的做法是引入一个编排器所有 Agent 都不直接对话而是通过编排器转发消息。每次消息都带 message_id、sender、receiver、task_id、payloadpayload 必须是结构化 JSON。这样每一个 Agent 本质上变成了一个独立的微服务对外只暴露出标准接口内部怎么耦合能力都行。编排器负责的任务分配、状态同步、超时控制是最适合落地的标准化边界。比如 Agent A 在等待 Agent B 的结果等待期间必须设置超时超过时限要么重试、要么走降级方案而不是无限等下去。多 Agent 协作里还有个容易被忽略的点每个 Agent 的输入输出要设计得足够窄。一个负责检索的 Agent输入就是查询参数输出就是检索结果集合。不要让它输出“我的理解是……”这样的自然语言东西结构化是最好的沟通语言。6. 常见问题与排查技巧实录6.1 高频问题速查表把之前遇到过的坑整理成一个速查表按现象分类遇到问题可以直接对号入座。问题现象常见原因排查思路解决方案同样的任务结果时好时坏模型在自由模式下决策不稳定对比多次执行的日志看哪一步开始分叉收紧状态机减少每个节点的可选动作Agent 输出的 JSON 解析失败模型在结构化输出前夹带了解释性文本查看原始输出确认格式漂移的具体形态改用 function calling让解析层直接拿 object多步任务偶尔遗漏中间结论上下文长度超限早期信息被截断或压缩打印每步的上下文信息确认结论什么时候丢失把关键中间结论显式写入上下文对象不依赖模型记忆模型升级后之前能跑通的流程开始失败新模型对工具描述或输出格式的遵从度有变化拉出升级前后对比日志跑回归集新模型先灰度与线上模型并行对比后再全量替换除了表格里这些还有两个问题出镜率特别高值得单独展开说一说。6.2 问题一Agent 拿起工具就放飞根本不按既定流程走这是我自己早年踩得最深的坑。当时做了一个简单的数据查询 Agent工具只开放了两个一个是订单查询一个是用户查询。模型拿到用户的问题之后经常自作主张先查了用户再拿着查出来的用户 ID 去查订单逻辑没错但偶尔又会调换顺序甚至在某些描述模糊的输入下连查好几次才能完成。这个问题花了我很大力气才发现根因工具描述里的空间给得太大了。模型是概率系统两个工具的用途和边界如果不清晰它就需要在每次调用时做一次“猜”的动作。后来我把两个工具的 description 写得更具体明确加了使用场景限制、参数要求、返回结构同时把流程改成用状态机约束先后顺序——必须先解析出用户 ID再进入订单查询状态。从那次之后顺序基本稳定了。这种问题的排查思路是先看日志里的工具调用序列和预设的状态机作对比找出“实际路径”和“预期路径”的第一个分叉点。然后针对分叉点做修复要么改工具描述要么加状态约束。千万不要觉得“模型再想想就会了”生产环境需要的是确定性不是概率。6.3 问题二线上模型悄悄变了行为就飘了模型升级导致 Agent 行为漂移是我觉得比代码还难防的问题。你代码一行没动提示词一个词没改线上 Agent 的行为就是变了。原因很简单很多基础模型的版本迭代会更新输出分布新版本对工具调用的遵从度、对 JSON 格式的稳定度、对指令的follow程度都会发生变化。有些变化是好的有些则会把之前能跑通的流程打乱。应对方式核心就一条换模型必须当线上发布流程来走不能直接拿上去就完事。先选一小部分流量灰度跑让旧模型和新模型并行处理同样的任务对比成功率、时延、合规率观察一段时间再决定是否全量。另外每换一次模型之前沉淀的回归集都要重新跑一遍。模型变了评估指标可能整体变化之前设置的阈值可能不再适用。要基于新模型的真实表现重新建立基线而不是拿着旧基线的数字去硬套。6.4 排查技巧从输出反推输入把黑盒拆成半透明最后分享一个我日常排查 Agent 问题最常用的技巧从输出反推输入配合日志逐步回溯。操作上分三步第一步拿到最终的错误输出确认是哪一层产生的。如果是工具调用报错直接看工具入参如果是校验失败看是哪个校验规则没通过。第二步沿着 task_id 找到整条执行链路日志重点看每个状态节点的输入和输出。这一下就能判断问题出在哪个节点是模型理解错了、工具返回错了、还是数据传递断了。第三步把出问题的那个节点的输入单独拿出来用同样的输入重新跑一次看能不能复现。如果能复现就是输入侧的问题如果不能可能是模型随机性导致的小概率事件需要增加重试机制或者条件判断来兜底。这个方法的核心就是把 Agent 从“一个神秘的黑盒”拆成“一个个带日志的灰色接口”。只要执行层被标准化了每步都有输入输出记录这种回溯操作就完全可行。如果遇到的是一个自由发挥、没有记录的 Agent那就没这么幸运了基本只能靠猜。结尾的一点实际体会做 Agent 项目这几年我最大的一个改观是Agent 能不能上生产和模型聪明不聪明关系其实没那么大和你的执行层干不干净关系非常大。模型再聪明也只是整个系统里的一环它需要被合适的流程、接口、护栏包裹住才能稳定地创造价值。我自己也曾在“要不要把流程定得这么死”这件事上纠结过担心标准化会不会把 Agent 的灵性磨掉。后来想明白了标准化约束的是执行路径不是能力上限。你可以把模型的能力都耦合进一个 Agent 里但每次执行都必须是可靠的、可观测的、可复制的。哪怕最后只记住一句话——先把执行钉死再放开能力——对你做下一个 Agent 项目都会有帮助。 Agent执行标准化：从自由调用到状态机约束的生产落地实践
说个我最近比较有共鸣的判断Agent 的能力可以随便耦合但它的执行必须标准化。这话不是我拍脑袋琢磨出来的而是最近读了一篇专门讨论 Agent 生产落地的论文之后再对照自己做过的一堆项目越品越觉得论文把很多团队踩过的坑提前画出来了。这篇文章不打算干巴巴复述论文而是把它背后的几个核心问题拆开讲为什么生产环境里的 Agent 和论文里的 Demo 完全是两回事、执行标准化到底要标准哪些东西、能力耦合的边界在哪里、以及真正出了问题怎么排查。我会把论文的实验逻辑和实际操作经验放在一起讲适合正在做 Agent 应用、或者正准备把 Agent 从原型推到生产环境的技术同学参考。先说结论放在前面如果你只记住了论文里的一句话那应该是“框架负责耦合能力流程负责标准化执行”。这句话值得贴在工位上。1. 那篇论文到底讲了个什么事1.1 三种架构的对比实验论文的实验设计其实非常朴素没有用什么花哨的 benchmark反而挑了三个偏真实工作流的任务集工单处理、文档分析、工具链调用。每个任务集里都存在多步骤的依赖关系比如先查用户信息再判断问题类型然后检索知识库最后生成回复并且创建记录。任务难度还做了分层简单任务步骤少复杂任务步骤多且存在分支。论文把同一个底座模型分别跑在三套架构上架构 A完全自由型 Agent。一个 Agent 拥有全部工具由模型自行决定调用顺序和调用时机不做任何流程约束。架构 B半约束型 Agent。系统提供一套流程模板作为参考模型可以偏离模板但偏离时会收到提示。架构 C全标准化 Agent。执行链路被拆成有限状态机解析、计划、执行、校验、输出每个节点只允许特定的工具和特定的输出格式。结果很有冲击力在简单任务上三套架构差距不大自由型甚至偶尔表现更好但任务一复杂差距立刻拉开。论文里的数据大致落在这样一个区间架构调用方式简单任务成功率复杂任务成功率A 自由调用模型自己决定一切84% 左右47% 左右B 模板引导有模板但允许偏离83% 左右52% 左右C 状态机约束强制按状态流转88% 左右73% 左右复杂任务上自由型和约束型的成功率差了超过二十个百分点。这个差距不是模型能力造成的因为底座模型是同一个。模型一样、工具一样唯一的变量就是执行层有没有被标准化。1.2 为什么“不自由”反而成功率高这个结论多少有点反直觉毕竟平时开发 Agent 的时候大家都希望模型发挥更大的自主性觉得自由度高就是智能。论文里给出的解释拆开看其实指向三个非常现实的问题。第一个是误差累计。一个复杂任务要拆成十几个步骤每步都有概率出现微小偏差比如选中了次优工具、漏了一个参数、或者对中间结果的理解出现了一点偏移。自由型架构下模型每一步都在“自由发挥”每步的偏差会慢慢累积越到后面越容易滚成一个大错误。而状态机架构把每一步的输入输出都卡死了模型只能在有限的选择里做决策偏差被约束在一个很小的范围内。第二个是决策稳定性。模型在开放选择空间下并不总能选到最优路径。工具描述写得再清楚也架不住几十个工具摆在一起模型有时候就是会选错。而标准化架构会把“在当前状态下只有两三个合法动作”作为一个硬条件模型做选择的压力小很多选对的概率自然上去了。第三个是出错后的定位成本。自由型架构一旦任务失败你很难说清楚到底是哪一步错了。是提示词写得不到位还是工具返回的结果有问题还是模型自己在某个环节开小差所有环节搅在一起排查成本很高。而状态机架构天然把流程切成了节点每个节点有独立的输入输出和日志失败发生在哪个节点一看便知。这里有个很重要的理解架构 C 并不是把 Agent 的“能力”阉割了。模型依然负责理解意图、做计划、组织语言、调用工具能力上是完整的。标准化的只是执行层的外在表现。这就是论文标题那句话的由来能力可以耦合执行必须标准化。2. 生产环境里的 Agent 到底乱在哪2.1 我见过或者踩过的几类典型事故论文里的实验设计对我来说很有画面感因为我在实际项目里见过太多对应的问题了。举几个真实场景。第一个案例是工具调用竞态。有个做内容生成的 Agent需求是先调用图片生成接口等图片返回后再调用排版接口。模型在自由模式下经常“急性子”图片接口还没返回完成它就已经开始调用排版接口结果排版接口拿到的是空地址整条流程直接失败。如果执行层有明确的状态控制要求必须收到图片接口的成功回执之后才允许进入下一个状态这类问题根本不会发生。第二个案例是上下文丢失。做过复杂任务 Agent 的应该都有体会模型一旦生成长文本或者多轮推理前面得出的中间结论可能被“挤”出上下文窗口。有个文档处理 Agent在处理几十页的 PDF 时前面几步已经判断出文档类型和关键字段但在后续步骤里它又忘记了这些结论重新开始分析导致处理结果前后矛盾。问题本质是中间状态没有落库全都依赖模型自己的记忆而模型记忆本来就是不可靠的。第三个案例是输出格式漂移。同一套提示词模型有时候输出标准 JSON有时候输出带 Markdown 代码块的 JSON有时候在 JSON 前后夹带几句解释。下游解析器只认 JSON于是出现间歇性失败。这种问题在自由文本输出模式下很难根除如果你要求模型必须通过工具调用而不是裸文本输出结构化结果稳定性会好很多。2.2 论文环境与生产环境的思维差异很多刚接触 Agent 的同学会困惑论文里的 Agent 看起来都挺聪明为什么我一放到生产环境就各种翻车这里面的核心差异其实是“能不能做”和“能不能一直做”的区别。维度论文 / 实验环境生产环境成功定义任务平均完成度允许部分失败可重复的完成率低方差失败率要压到很低容错能力高bad case 可以事后分析低一个严重错误可能就是线上事故可观测性可以重新跑实验边跑边加日志必须先有日志事后不能重放现场交接运维论文作者自己维护几周任何一个工程师都能接手维护迭代方式换更好的模型就行换模型要过回归测试任何变更都要有对照这个表我用过很多次每次拿给团队看都挺扎心。原因是研究者和工程师面对同一个 Agent 时默认的评价方式其实是打架的。研究视角下模型能不能处理一个没见过的复杂问题是核心工程视角下一个已经能跑的流程会不会在边界条件下突然出错才是核心。我自己以前也吃过类似的亏。第一个 Agent 项目上线前我很兴奋觉得模型很聪明各种刁钻的输入都能接得住。结果一放量开始出现各种以前测试时完全没见过的输入模型开始“自由发挥”偶尔冒出几句不可控的输出直接把下游系统搞崩。从那时候起我就下了个决心Agent 的能力可以强但每一次执行必须像流水线一样可预期。3. Agent 执行标准化到底要标准哪些事3.1 流程标准化用状态机代替自由发挥流程标准化是最底层的一层也是让 Agent 从“Demo 级”走向“生产级”最关键的一步。我的做法是把一个 Agent 任务抽象成有限状态机每个状态代表执行链路中的一个阶段状态之间的转移条件必须显式声明。常用的状态集合大致是这样RECEIVE接收原始请求完成基础解析比如识别意图、提取关键参数。PLAN任务拆解选定工具生成执行计划。EXECUTE逐项调用工具获取中间结果。VERIFY对执行结果做校验包括格式校验和业务规则校验。OUTPUT输出结构化结果或者进入转人工流程。ESCALATE失败重试或者升级给人工处理。状态机最大的好处是它天然只有有限条合法路径可以穷举验证。每一次任务执行最终都能落在少数几种结局里——成功输出、重试、升级。出问题的时候可以根据当前状态直接定位环节不需要去猜测模型刚才在想什么。设计状态机的时候有三个原则值得记住。第一状态数量宁少勿多语义要清晰不要为了追求精细拆出十几个状态那样维护成本会很高。第二状态转移条件必须显式声明不能用“如果模型觉得合适就跳转”这种话要落到具体的判断逻辑上。第三每个状态都要有超时和告警一个状态卡了超过设定时间要能自动触发告警或者进入升级流程。这里补充一个实操心得状态机并不是要把模型“圈养”起来。恰恰相反我会在 PLAN 和 EXECUTE 这两个状态里给模型留足自由度让它能自主选择工具和参数只是把选择范围从“所有工具”收敛到“当前任务域内的工具”。这种折中既保住了灵活性又避免了模型在海量工具中迷失方向。3.2 接口标准化输入输出必须带 Schema流程标准化管的是“每一步做什么”接口标准化管的是“每一步怎么传数据”。如果每个环节的输入输出格式不统一状态机再清晰也会被乱七八糟的数据冲垮。接口标准化要覆盖三层。第一层是工具接口。每个工具暴露出来的输入输出都要有严格 Schema描述里不要写模糊的话。工具描述尽量只承担单一职责一个工具只干一件事描述里明确适用场景、参数格式、返回格式、还有使用限制。比如一个知识库检索工具描述里面不要写“可以搜索任何资料”要写成“在技术支持知识库中检索与问题相关的文档仅用于技术咨询不用于订单和财务问题”。这样模型在选择工具时误判概率会低很多。第二层是模型输出接口。在真实生产项目里我不太建议让模型用自然语言直接输出全部结果除非是最终面向用户的回复。中间环节的结构化结果比如意图分类、抽取出的参数、校验结果都应该通过函数调用或者结构化生成来产出。你可以在提示词里写“必须且只能输出 JSON”但更可靠的方式是在架构层面要求模型通过 function calling 返回结构化结果让解析层直接拿到 object而不是拿文本再解析一次。第三层是数据协议。整个执行链路中的上下文传递字段名、类型、嵌套结构要全局统一。一个典型的上下文结构长这样{ task_id: task_20250101_001, state: EXECUTE, input: { raw_text: 用户反馈登录页面打不开, parsed: { intent: fault, entities: { product: app, symptom: login_failure } } }, context: { user_id: u_10001, source: customer_service }, intermediate: { knowledge_docs: [doc_01, doc_02] }, final_output: null }每个字段都有明确含义每个环节把自己产生的结果写入对应字段不覆盖不属于自己的字段。这样做还有个额外好处整条链路的输入输出都可以被打日志记录下来事后复盘非常清晰。3.3 评估标准化Agent Evals 要变成回归集聊到 Agent 评估很多人第一反应是“拿几个测试用例跑一遍看看回答准不准”。这个思路在原型阶段没问题但离生产级的要求差得很远。生产环境真正需要的是可回归、可对比、可量化的评估体系而不是一个“凭感觉还行”的主观评价。我自己做 Agent Evals 的时候一般分四步走。第一步沉淀真实样本集。把过去两三个月生产环境里遇到的真实任务收集起来按照业务场景分类大致覆盖高频场景和典型边界场景。样本量至少要有上百条太少了做不了对比。第二步定义多维指标。任务完成率当然要关注但不能只看这一个。我通常同时看步骤合规率、平均时延、单任务 token 成本、转人工比例这几个维度。步骤合规率很重要它反映的是 Agent 有没有按照标准化流程去执行而不是只看最后的输出结果对不对。第三步建立基线。用当前线上版本的 Agent 跑一遍回归集记录各项指标作为基线。之后每一次改动不管是改提示词、换模型、调工具都重新跑一遍和基线对比。第四步把评估结果和运维数据打通。线上系统每天产生大量真实执行记录把这些记录自动回流到评估集里。遇到线上事故立刻把出事的这条输入加入回归集确保以后同样的场景不会再被忽略。这套评估体系看起来麻烦但真的能救命。我团队里曾经为了一个很小的问题——把工具描述里的一个词从“获取”改成“查询”——到底有没有影响直接跑了整轮回归发现某个边角场景的成功率掉了一点五个百分点。如果没有评估体系这种细微的退化根本发现不了等线上出问题再查浪费的时间和精力会比跑回归多得多。4. 一个可抄作业的落地案例客服工单 Agent4.1 场景拆解与状态机设计前面讲了很多原则这里用一个具体的例子把它们串起来。我选的是“客服工单 Agent”因为这个场景足够通用而且天然依赖多步骤执行非常适合展示标准化怎么做。需求背景技术支持团队每天收到大量用户反馈需要 Agent 判断问题类型、检索知识库、生成解决方案必要时创建内部工单。全部通过人工处理成本太高直接让模型自由发挥又不可控所以要做成标准化执行的状态机。状态机设计如下intent意图识别区分账号问题、使用咨询、故障报修、其他。retrieve根据意图检索知识库取回相关文档。generate基于检索结果生成回复草稿。validate校验草稿是否覆盖关键信息比如是否引用了知识库来源、是否包含可执行的操作步骤。respond通过校验则输出回复校验不通过则进入 escalate。escalate转接人工客服附上当前上下文和失败原因。这个状态机和第四章抽象模型的思路一致只是针对客服场景做了瘦身。每个状态做的事情非常明确状态之间的跳转也完全确定。比如 generate 完成后直接进 validatevalidate 只有两个出口通过进 respond不通过进 escalate不存在“模型觉得差不多就继续”这种模糊情况。4.2 关键实现细节第一个细节是每个状态的输出必须结构化。以 intent 状态为例它输出的不是一句“用户遇到了登录问题”的自然语言而是一段稳定的 JSON{ category: fault, confidence: 0.92, extracted: { product: app, symptom: login_failure, os: android } }这样下游 retrieve 状态不需要再理解自然语言直接根据 category 和 extracted 字段去检索就行。第二个细节是知识库工具的描述要写得足够“窄”。一个检索工具的描述示例是这样{ name: search_knowledge_base, description: 在技术支持知识库中检索与问题相关的文档仅用于技术咨询类问题不用于订单、财务类查询。, parameters: { type: object, properties: { query: { type: string, description: 检索关键词尽量提取核心名词比如登录失败、闪退 }, top_k: { type: integer, description: 返回文档数量默认5最大10 } }, required: [query] } }第三个细节是提示词模板要围绕状态组织。generate 状态的提示词大致是这个风格你是一名技术支持助手。 当前任务状态生成回复。 用户原始反馈{raw_text} 已检索到的知识库文档{docs} 请根据以上文档生成回复要求包含具体操作步骤并在末尾标注引用来源。 输出格式严格 JSON。 {json_schema}这些细节每一项单独看都不复杂但组合在一起效果就出来了。模型发挥的空间被约束在“怎么表达”上而不是“要不要遵守流程”上。即使这次生成的回复不合格也可以明确知道是在 validate 状态被拦下来的而不是莫名其妙地在某个无规则的环节失败了。4.3 配套的可观测性配置执行标准化的另一面是可观测。如果每步执行不落日志标准化就没有意义。客服工单 Agent 上线的时候我在日志和追踪上做了三件事。第一每个任务从进入系统开始就生成一个 task_id贯穿所有状态和所有工具调用。每一条日志、每一次模型调用、每一个工具返回都带上这个 task_id。这样遇到有用户投诉“回复不对”可以直接通过 task_id 把整条执行链捞出来。第二每个状态执行时记录输入、输出、耗时、token 消耗。这些数据不仅要供排查用还能用来做成本分析和性能分析。哪个状态耗 token 最多哪个流程经常卡在哪个状态通过统计日志都能看出来。第三建立反馈闭环。客服工单 Agent 的回复发给用户之后用户的后续行为要回流。用户点了“有帮助”还是“没帮助”有没有再追加问题这些数据全部回流到评估集里。这样每一个执行结果都成为下一次迭代的养料。代码骨架其实很简单核心就是一个状态循环import enum class Step(enum.Enum): INTENT intent RETRIEVE retrieve GENERATE generate VALIDATE validate RESPOND respond ESCALATE escalate def run_agent(raw_text: str, context: dict) - dict: ctx { task_id: generate_task_id(), raw_text: raw_text, context: context, state: Step.INTENT, intermediate: {}, } while True: state ctx[state] if state Step.INTENT: ctx[intermediate][intent] classify_intent(raw_text) ctx[state] Step.RETRIEVE elif state Step.RETRIEVE: ctx[intermediate][docs] search_knowledge_base(...) ctx[state] Step.GENERATE elif state Step.GENERATE: ctx[intermediate][draft] generate_reply(...) ctx[state] Step.VALIDATE elif state Step.VALIDATE: if validate_reply(ctx[intermediate]): ctx[state] Step.RESPOND else: ctx[state] Step.ESCALATE elif state Step.RESPOND: return send_reply(ctx) else: return escalate_to_human(ctx)这段代码言简意赅真实项目里每个函数都会更复杂但骨架变不了。我最喜欢这个模式的地方在于它把 Agent 的“智能感”收敛到了若干个决策点上其余部分全部是确定性的工程逻辑。这恰恰是生产环境最需要的东西。5. 能力耦合的边界在哪里5.1 哪些能力可以放心地耦合在一起既然说“能力可以耦合”那到底哪些能力可以放心地揉在一起我的判断标准也很简单看这个能力是不是在同一任务域内、是不是遵循同样的业务约束、是不是可以被独立替换。同一任务域内的能力适合耦合。比如客服 Agent 里的意图识别、知识库检索、回复生成这三者围绕的都是“回答用户问题”这个目标领域一致数据结构也天然衔接放在一个 Agent 内部非常自然。这种情况下硬拆成多个微服务反而会因为接口调用开销而拖慢速度。可以复用的能力也适合耦合。比如记忆组件不管是长期记忆还是短期记忆它们提供服务的方式是一样的底层存储也是同一套就没有必要拆成两个 Agent 来管。再比如 RAG 的检索加重排检索完紧接着重排中间状态不外泄这种流水线式能力封装在一起更高效。耦合的核心原则是高内聚、低耦合、可替换。高内聚是让同一个领域的能力聚在一起低耦合是让不同领域之间只通过标准消息通信可替换是任何一个能力组件都可以被替换而不影响主流程。只要满足这三条能力耦合得再深也不用怕。5.2 哪些能力必须放在 Agent 外部能力耦合不是没有边界有几类能力我强烈建议永远不要放进 Agent 内部。权限控制必须外置。Agent 不能自己决定“当前用户有没有权限执行这个操作”权限判断必须是外部代码用确定性的规则完成。模型可以猜测用户意图但绝不能让模型拍板“放行”。我见过有团队让 Agent 根据用户描述动态判断打折权限结果被恶意输入绕过规则最后还是要人工介入处理。审计与溯源必须外置。Agent 的所有行为都要留痕并且这个留痕机制不能依赖 Agent 自己“想起来要记”。日志要由外部审计服务统一记录Agent 只负责执行记录是执行环境强制的。这样即使 Agent 被搞崩溃了日志还在。安全与脱敏必须外置。任何进入 Agent 的输入、任何从 Agent 出去的输出都要经过外部安全组件。脱敏、拦截、内容合规检查不能交给模型“自觉”。模型本质上是概率系统你没法保证它在高压场景下每次都做对。成本控制也必须外置。单任务的最大 token 数、最大工具调用次数、单次调用的超时时间都应该是执行环境层面的硬限制而不是提示词里的“建议”。我做过一个 Agent模型在一个错误分支里连续调用了十几次工具要不是设置了次数上限一次任务的成本就够喝一壶的了。这些能力外置之后Agent 反而更纯粹了它负责理解和产出安全、权限、成本由外围的护栏统一兜住。这个模式和“能力可以耦合执行必须标准化”是一个逻辑。5.3 多 Agent 协作同样适用这套逻辑如果你已经踩上了多 Agent 协作的坑应该会深刻理解为什么执行标准化在多 Agent 场景下更重要。很多团队一上来就搞“自由协商”让两个 Agent 直接用自然语言对话来完成任务。听起来很智能实际跑起来就像开一个没人控场的在线会议聊着聊着就跑题了。生产环境下的多 Agent 协作更接近微服务之间的通信协议而不是人与人之间的聊天。我的做法是引入一个编排器所有 Agent 都不直接对话而是通过编排器转发消息。每次消息都带 message_id、sender、receiver、task_id、payloadpayload 必须是结构化 JSON。这样每一个 Agent 本质上变成了一个独立的微服务对外只暴露出标准接口内部怎么耦合能力都行。编排器负责的任务分配、状态同步、超时控制是最适合落地的标准化边界。比如 Agent A 在等待 Agent B 的结果等待期间必须设置超时超过时限要么重试、要么走降级方案而不是无限等下去。多 Agent 协作里还有个容易被忽略的点每个 Agent 的输入输出要设计得足够窄。一个负责检索的 Agent输入就是查询参数输出就是检索结果集合。不要让它输出“我的理解是……”这样的自然语言东西结构化是最好的沟通语言。6. 常见问题与排查技巧实录6.1 高频问题速查表把之前遇到过的坑整理成一个速查表按现象分类遇到问题可以直接对号入座。问题现象常见原因排查思路解决方案同样的任务结果时好时坏模型在自由模式下决策不稳定对比多次执行的日志看哪一步开始分叉收紧状态机减少每个节点的可选动作Agent 输出的 JSON 解析失败模型在结构化输出前夹带了解释性文本查看原始输出确认格式漂移的具体形态改用 function calling让解析层直接拿 object多步任务偶尔遗漏中间结论上下文长度超限早期信息被截断或压缩打印每步的上下文信息确认结论什么时候丢失把关键中间结论显式写入上下文对象不依赖模型记忆模型升级后之前能跑通的流程开始失败新模型对工具描述或输出格式的遵从度有变化拉出升级前后对比日志跑回归集新模型先灰度与线上模型并行对比后再全量替换除了表格里这些还有两个问题出镜率特别高值得单独展开说一说。6.2 问题一Agent 拿起工具就放飞根本不按既定流程走这是我自己早年踩得最深的坑。当时做了一个简单的数据查询 Agent工具只开放了两个一个是订单查询一个是用户查询。模型拿到用户的问题之后经常自作主张先查了用户再拿着查出来的用户 ID 去查订单逻辑没错但偶尔又会调换顺序甚至在某些描述模糊的输入下连查好几次才能完成。这个问题花了我很大力气才发现根因工具描述里的空间给得太大了。模型是概率系统两个工具的用途和边界如果不清晰它就需要在每次调用时做一次“猜”的动作。后来我把两个工具的 description 写得更具体明确加了使用场景限制、参数要求、返回结构同时把流程改成用状态机约束先后顺序——必须先解析出用户 ID再进入订单查询状态。从那次之后顺序基本稳定了。这种问题的排查思路是先看日志里的工具调用序列和预设的状态机作对比找出“实际路径”和“预期路径”的第一个分叉点。然后针对分叉点做修复要么改工具描述要么加状态约束。千万不要觉得“模型再想想就会了”生产环境需要的是确定性不是概率。6.3 问题二线上模型悄悄变了行为就飘了模型升级导致 Agent 行为漂移是我觉得比代码还难防的问题。你代码一行没动提示词一个词没改线上 Agent 的行为就是变了。原因很简单很多基础模型的版本迭代会更新输出分布新版本对工具调用的遵从度、对 JSON 格式的稳定度、对指令的follow程度都会发生变化。有些变化是好的有些则会把之前能跑通的流程打乱。应对方式核心就一条换模型必须当线上发布流程来走不能直接拿上去就完事。先选一小部分流量灰度跑让旧模型和新模型并行处理同样的任务对比成功率、时延、合规率观察一段时间再决定是否全量。另外每换一次模型之前沉淀的回归集都要重新跑一遍。模型变了评估指标可能整体变化之前设置的阈值可能不再适用。要基于新模型的真实表现重新建立基线而不是拿着旧基线的数字去硬套。6.4 排查技巧从输出反推输入把黑盒拆成半透明最后分享一个我日常排查 Agent 问题最常用的技巧从输出反推输入配合日志逐步回溯。操作上分三步第一步拿到最终的错误输出确认是哪一层产生的。如果是工具调用报错直接看工具入参如果是校验失败看是哪个校验规则没通过。第二步沿着 task_id 找到整条执行链路日志重点看每个状态节点的输入和输出。这一下就能判断问题出在哪个节点是模型理解错了、工具返回错了、还是数据传递断了。第三步把出问题的那个节点的输入单独拿出来用同样的输入重新跑一次看能不能复现。如果能复现就是输入侧的问题如果不能可能是模型随机性导致的小概率事件需要增加重试机制或者条件判断来兜底。这个方法的核心就是把 Agent 从“一个神秘的黑盒”拆成“一个个带日志的灰色接口”。只要执行层被标准化了每步都有输入输出记录这种回溯操作就完全可行。如果遇到的是一个自由发挥、没有记录的 Agent那就没这么幸运了基本只能靠猜。结尾的一点实际体会做 Agent 项目这几年我最大的一个改观是Agent 能不能上生产和模型聪明不聪明关系其实没那么大和你的执行层干不干净关系非常大。模型再聪明也只是整个系统里的一环它需要被合适的流程、接口、护栏包裹住才能稳定地创造价值。我自己也曾在“要不要把流程定得这么死”这件事上纠结过担心标准化会不会把 Agent 的灵性磨掉。后来想明白了标准化约束的是执行路径不是能力上限。你可以把模型的能力都耦合进一个 Agent 里但每次执行都必须是可靠的、可观测的、可复制的。哪怕最后只记住一句话——先把执行钉死再放开能力——对你做下一个 Agent 项目都会有帮助。