Agent上生产：从Demo到工业级落地的可控性架构设计

1. 一个让所有Agent开发者都绕不开的灵魂拷问“不受控的 Agent凭什么上生产系统”这个问题我第一次在团队内部评审会上被问到的时候会议室安静了大概五秒钟。当时我们正在推一个基于 Agent 架构的自动化运维助手演示环节一切顺利Demo 跑得漂漂亮亮结果负责生产环境的老哥直接甩了这么一句。说实话那五秒钟里我脑子里闪过了无数个“好像确实没法反驳”的瞬间。这两年 Agent 这个概念火得一塌糊涂从 agent 开发、agent 框架到多 agent 协作各种技术社区里天天有人在讨论 agent 架构、agent 记忆、agent skills。但如果你真正在工业级场景里落地过就会发现一个很尴尬的现实大部分 Agent 项目停留在“能跑通”的阶段离“敢上生产”之间隔着一条巨大的鸿沟。这条鸿沟不是模型能力不够而是可控性的问题。所谓“不受控”不是说 Agent 会突然失控干坏事而是指它的行为边界模糊、输出不确定、错误不可预测、状态不可追溯。你没法回答“它为什么做了这个决策”“它下次还会不会做同样的决策”“它做错了怎么回滚”这三个问题那生产系统就不可能接纳它。生产系统要的不是聪明是确定性。这篇内容我想聊的就是这件事一个 Agent 项目从“能演示”到“能上生产”中间到底需要补哪些课。我会从架构设计、记忆管理、执行控制、评估体系、安全防护几个维度展开结合我自己踩过的坑和行业里常见的实践方案给出一套可参考的落地思路。不管你是刚开始学 agent 开发还是已经在做 agent 项目准备上生产应该都能从中找到对自己有用的东西。2. 先搞清楚生产系统到底在怕什么2.1 生产系统的三条底线在讨论 Agent 怎么上生产之前得先弄明白生产系统对任何组件的底线要求是什么。我总结下来就三条第一条是可预测性。同样的输入即使不能保证完全相同的输出至少要在可接受的范围内波动。传统软件里一个函数输入 11 永远等于 2但 Agent 不一样它背后是大语言模型同样的 prompt 可能今天给你一个答案明天给你另一个。生产系统可以接受一定程度的概率性但必须能界定这个概率性的边界。第二条是可追溯性。出了问题要能查到原因。传统系统里一个请求失败了你看日志能追到具体哪一行代码抛了异常。Agent 呢它可能调了三次工具、检索了五段记忆、经过了两轮推理最后给了一个错误答案。如果你没有完整的执行链路记录排查就无从下手。第三条是可回滚性。做错了要能撤回来。Agent 如果只是生成一段文本那回滚很简单重新生成就行。但如果 Agent 对接了真实系统比如自动修改了配置、自动下了订单、自动发了邮件那回滚就复杂了。生产系统必须确保 Agent 的每一个有副作用的操作都是可撤销的或者至少是可补偿的。这三条底线听起来简单但每一条都对 Agent 的架构设计提出了很高的要求。很多 agent 框架在 Demo 阶段根本不考虑这些因为 Demo 只需要“跑通”不需要“跑稳”。2.2 Agent 为什么天然“不受控”Agent 之所以难以控制根源在于它的工作方式和传统程序有本质区别。传统程序是确定性逻辑驱动的你写 if-else它就按 if-else 走。Agent 是目标驱动的你给它一个目标它自己决定怎么拆解、怎么执行、用什么工具、调什么记忆。这个“自己决定”的过程就是不确定性的来源。具体来说不确定性来自几个层面。模型层面大语言模型本身是概率性的temperature 参数哪怕调到 0不同版本的模型、不同的推理框架也可能给出不同结果。编排层面Agent 的规划能力决定了它怎么拆任务但规划本身是模型生成的可能这次拆成三步下次拆成五步。工具层面Agent 调用外部工具时工具的返回结果可能变化Agent 对返回结果的解读也可能变化。记忆层面Agent 从记忆里检索什么、怎么用同样是不确定的。这四个层面的不确定性叠加在一起就导致了一个结果你很难对 Agent 的行为做静态分析。传统程序你可以做代码审查、可以做形式化验证但 Agent 的行为空间太大了你没法穷举。2.3 “可控”到底意味着什么那什么叫“可控”我的理解是可控不是让 Agent 变得完全确定而是让它的不确定性变得可管理。具体来说包括几个方面行为边界可控Agent 能做什么、不能做什么有明确的约束不是靠 prompt 里写一句“请不要做危险操作”就完事了。执行过程可控Agent 每一步在干什么有实时的监控和干预手段出问题能及时刹车。输出质量可控Agent 的输出经过验证和过滤不合格的不会流到下游。状态变化可控Agent 对系统状态的修改有事务性保障要么全成功要么全回滚。演化过程可控Agent 的 prompt、工具、记忆更新有版本管理能回退到已知good state。这五个“可控”做到了Agent 才具备上生产系统的基本资格。接下来我逐个展开讲怎么实现。3. 架构层面的可控性设计3.1 从“单体 Agent”到“分层可控架构”很多 agent 项目一开始都是单体结构一个 prompt 模板、几个工具、一个循环跑起来就完事。这种结构在 Demo 阶段没问题但上生产就会暴露各种问题。我的建议是从一开始就采用分层架构把不同职责拆开。一个典型的分层可控架构大概长这样接入层负责请求接收、身份认证、限流、审计日志。这一层和传统 Web 服务没区别但它是 Agent 可控性的第一道防线。编排层负责 Agent 的规划、任务拆解、工具调度。这一层是 Agent 的核心也是不确定性最大的地方需要重点设计。执行层负责具体工具的调用、外部系统的交互。这一层要保证每个操作都是幂等的、可回滚的。记忆层负责短期、长期、永久记忆的存储和检索。这一层要保证记忆的写入和读取都是可控的。评估层负责对 Agent 的输出做质量评估和安全检查。这一层是输出质量的守门人。分层的核心目的是隔离不确定性。编排层可以不确定但执行层必须确定记忆层可以模糊检索但评估层必须严格判断。每一层只做自己该做的事层与层之间通过明确的接口通信这样任何一层出问题都不会直接击穿整个系统。3.2 编排层的确定性约束编排层是 Agent 最“自由”的地方也是最需要约束的地方。我见过很多 agent 项目编排逻辑全靠一个 system prompt 撑着模型想怎么规划就怎么规划这在上生产时是灾难性的。我的做法是给编排层加几层约束。第一层是工具白名单Agent 只能调用预先注册的工具不能动态生成工具调用。第二层是步骤上限一个任务最多执行多少步超过就强制终止防止 Agent 陷入死循环。第三层是状态机约束把 Agent 的执行过程建模成有限状态机每个状态允许的转移是预定义的模型只能在允许的转移里选。举个例子假设你做一个客服 Agent状态机可能是理解问题 - 检索知识 - 生成回复 - 审核回复 - 发送回复。模型不能从“理解问题”直接跳到“发送回复”必须经过中间状态。这样即使模型抽风也不会跳过审核环节。状态机的定义不需要很复杂用简单的配置就能描述。关键是要让编排逻辑从“模型自由发挥”变成“模型在框架内选择”。3.3 执行层的幂等与回滚执行层直接对接外部系统是副作用最大的地方。这里的核心原则是每个操作都要幂等每个副作用都要可回滚。幂等的意思是同一个操作执行多次和执行一次的效果一样。比如“设置订单状态为已支付”是幂等的“订单金额加 100”就不是。Agent 在执行工具调用时可能因为网络问题重试如果操作不幂等就会出问题。所以对接外部系统的接口尽量设计成幂等的或者用唯一请求 ID 做去重。回滚的意思是操作做错了能撤回来。对于数据库操作可以用事务对于 API 调用可以设计补偿接口对于发邮件、发消息这类不可撤回的操作就要在执行前做二次确认或者先发到草稿箱再人工确认。我自己的经验是把 Agent 的工具分成三类只读工具查询类随便调、可逆写工具能回滚的写操作、不可逆写工具不能回滚的写操作。不可逆写工具必须经过人工确认才能执行或者至少要有强制的延迟执行窗口给人工干预留时间。3.4 一个可参考的架构配置下面是一个我实际用过的编排层配置示例用 YAML 描述可以直接参考agent: name: ops-assistant max_steps: 15 max_tool_calls: 8 timeout_seconds: 120 state_machine: initial: understand states: understand: allowed_next: [retrieve, clarify] retrieve: allowed_next: [plan, clarify] plan: allowed_next: [execute, abort] execute: allowed_next: [execute, verify, abort] verify: allowed_next: [respond, execute, abort] respond: allowed_next: [end] clarify: allowed_next: [understand, end] abort: allowed_next: [end] tools: read_only: - query_metrics - search_logs - get_service_status reversible: - restart_service - scale_replicas irreversible: - delete_data - modify_config - send_notification irreversible_requires_approval: true这个配置里max_steps和max_tool_calls是硬性上限防止无限循环。状态机定义了允许的状态转移模型只能在允许的范围内选择。工具按风险等级分类不可逆操作需要审批。这套配置不复杂但能挡住大部分“不受控”的情况。4. 记忆管理Agent 可控性的隐形战场4.1 短期、长期、永久记忆的分层设计Agent 记忆是这两年讨论很多的话题从 agent 记忆框架选型到短期、长期、永久记忆的实现各种方案层出不穷。但我想说的是记忆管理不只是“让 Agent 记住更多东西”更是“让 Agent 的记忆可控”。我的实践是把记忆分成三层短期记忆就是当前会话的上下文存在内存里会话结束就清掉。这一层的关键是控制长度不能无限增长否则既影响性能又影响模型注意力。常见的做法是滑动窗口加摘要超过一定长度就把早期内容压缩成摘要。长期记忆是跨会话的持久化记忆存在数据库或向量库里。这一层的关键是写入控制不是什么信息都往里塞。我的做法是给记忆写入设一个“重要性阈值”只有超过阈值的信息才写入长期记忆避免记忆库被垃圾信息污染。永久记忆是 Agent 的核心知识和规则比如业务规则、操作手册、历史决策记录。这一层的关键是版本管理每次更新都要有记录能回退到之前的版本。三层记忆的读写策略不一样。短期记忆读写频繁但生命周期短长期记忆读写较少但需要检索效率永久记忆读多写少但要求强一致性。分开设计才能各司其职。4.2 记忆写入的“安检”机制记忆写入是 Agent 可控性最容易出问题的地方。如果 Agent 把错误信息、临时状态、甚至恶意注入的内容写进了长期记忆那后续所有基于这些记忆的决策都会受影响。这就是为什么现在 agent 安全领域开始关注记忆防护比如 a-memguard 这类主动防御框架的思路。我在实际项目里加了一个记忆写入的“安检”流程分三步第一步是来源验证。只有来自可信来源的信息才能写入长期记忆。用户输入、外部 API 返回、模型生成的内容可信度是不一样的。用户输入需要过滤外部 API 返回需要校验模型生成的内容需要审核。第二步是内容过滤。写入前检查内容是否包含敏感信息、是否与已有记忆冲突、是否符合业务规则。冲突检测很重要如果新记忆和旧记忆矛盾要么拒绝写入要么标记冲突让人工处理。第三步是写入审计。每次写入都记录来源、时间、内容摘要、写入原因。这样出问题能追溯也能定期审查记忆库的健康度。这三步听起来麻烦但实现起来不复杂一个中间件就能搞定。关键是意识上要重视不能觉得“记忆嘛存进去就完事了”。4.3 记忆检索的相关性与时效性记忆检索是另一个容易出问题的地方。Agent 从记忆库里检索信息时如果检索不准要么漏掉关键信息要么引入无关信息干扰决策。相关性方面向量检索是主流方案但纯向量检索有时候会漏掉关键词匹配的结果。我的做法是混合检索向量检索加关键词检索两路结果合并后重排序。重排序可以用一个小的交叉编码器模型也可以用简单的规则加权。时效性方面记忆是有保质期的。三个月前的服务状态和现在的服务状态可能完全不同如果 Agent 检索到旧记忆当新记忆用就会出错。所以每条记忆都要带时间戳检索时根据时效性做衰减。越旧的记忆权重越低超过一定时间的记忆要么归档要么标记为“历史参考”。还有一个细节是记忆的粒度。太粗的记忆检索出来没用太细的记忆检索出来太多。我的经验是按“事件”为单位存记忆一个事件包含时间、主体、动作、结果、上下文这样检索出来直接可用。4.4 记忆冲突的处理策略记忆冲突是不可避免的。同一个问题不同时间可能有不同答案同一个操作不同人可能有不同记录。冲突处理不好Agent 就会精神分裂。我的策略是优先级加人工仲裁。每条记忆带一个优先级来源越权威、时间越近、被引用次数越多的记忆优先级越高。检索到冲突记忆时优先用高优先级的。如果优先级相同就标记冲突交给人工仲裁仲裁结果写回记忆库作为新的高优先级记忆。这个机制的关键是不要让模型自己仲裁冲突。模型没有判断哪个记忆更可信的能力让它仲裁只会引入更多不确定性。人工仲裁虽然慢但可靠。5. 执行控制让 Agent 的手脚被管住5.1 工具调用的权限模型Agent 的能力很大程度上取决于它能调用什么工具。工具越多能力越强但风险也越大。所以工具调用必须有权限模型。我的做法是基于角色的工具权限。不同场景下的 Agent 实例授予不同的工具集。比如只读查询场景的 Agent 只能调只读工具运维操作场景的 Agent 才能调写工具。权限配置在 Agent 启动时注入运行时不动态变更。权限模型还要考虑参数级权限。同一个工具不同参数的风险不一样。比如restart_service工具重启测试环境的服务和重启生产环境的服务风险完全不同。所以权限控制要细到参数级生产环境的参数需要额外审批。实现上可以用一个策略引擎每次工具调用前检查这个 Agent 有没有权限调这个工具这个参数值在不在允许范围内需不需要额外审批策略引擎的规则用配置描述方便调整。5.2 执行过程的实时监控与干预Agent 执行过程中必须有实时监控。监控什么至少监控这几项当前执行到哪一步、已经调了哪些工具、每步耗时多少、有没有异常。监控数据要实时展示最好有个 dashboard。运维人员能看到 Agent 在干什么发现不对能及时干预。干预手段包括暂停执行、终止执行、修改下一步的参数、跳过当前步骤。我踩过的一个坑是早期版本没有实时监控Agent 卡在一个循环里跑了半小时才发现白白浪费了资源还产生了一堆垃圾日志。后来加了监控和超时强制终止这类问题就再没出现过。监控还有一个作用是积累数据。Agent 每次执行的完整链路记录下来就是宝贵的评估数据。哪些步骤容易出错、哪些工具调用失败率高、哪些场景耗时最长这些数据是后续优化的基础。5.3 超时、重试与熔断策略Agent 调用外部工具时网络抖动、服务不可用是常态。没有超时和重试策略Agent 就会卡死。超时策略要分层设置。单次工具调用超时、单步执行超时、整个任务超时三个层次都要有。单次工具调用超时一般设 10-30 秒单步执行超时设 60 秒整个任务超时根据业务定一般不超过 5 分钟。重试策略要区分错误类型。网络超时可以重试参数错误重试没用服务端 5xx 可以重试4xx 不要重试。重试次数一般 2-3 次用指数退避避免雪崩。熔断策略是防止 Agent 在某个服务持续失败时还不断重试。连续失败 N 次后熔断一段时间期间直接返回失败不再调用。熔断时间到了再半开试探性放一个请求过去成功就恢复失败就继续熔断。这三个策略组合起来能保证 Agent 在面对外部故障时不会失控。5.4 一个工具调用的完整控制流程把上面的东西串起来一个工具调用的完整控制流程大概是Agent 决定调用工具生成调用请求。策略引擎检查权限Agent 有没有权限参数是否合法是否需要审批如果需要审批暂停执行通知人工审批。审批通过继续不通过终止。检查熔断状态该工具对应的服务是否在熔断中是则直接失败。执行工具调用带超时控制。如果失败判断错误类型决定是否重试。如果重试多次仍失败记录失败返回错误给 Agent。如果成功记录调用日志返回结果给 Agent。如果是有副作用的操作记录回滚信息以便需要时回滚。这个流程看起来步骤多但每一步都是必要的。少了任何一步可控性就打折扣。6. 评估体系怎么知道 Agent 干得好不好6.1 Agent 评估和传统测试的区别传统软件测试有明确的预期输出输入 A 期望输出 B对不上就是 bug。Agent 评估没这么简单因为 Agent 的输出是自然语言同一个意思可以有无数种表达而且很多任务没有唯一正确答案。所以 Agent 评估需要一套不同的方法论。现在行业里讨论比较多的 agent evals核心思路是多维度评估加人工校准。多维度包括任务完成度、输出质量、执行效率、安全性、成本。人工校准是因为自动评估总有盲区需要人工抽查来发现自动评估漏掉的问题。我的经验是Agent 评估不能追求 100% 自动化但也不能全靠人工。合理的比例是自动评估覆盖 80% 的常规场景人工评估覆盖 20% 的边界场景和抽样检查。6.2 构建评估数据集的实操方法评估数据集是评估体系的基础。没有好的数据集评估就是空中楼阁。构建数据集的第一步是收集真实场景。从生产日志里捞、从用户反馈里找、从客服工单里提取。真实场景的价值在于它包含了各种边界情况是人工构造数据很难覆盖的。第二步是标注预期结果。不是标注唯一正确答案而是标注可接受的结果范围。比如一个客服回复任务标注“必须包含退款政策说明”“不能承诺超出政策的补偿”“语气要礼貌”而不是标注一段标准回复。第三步是分层组织。按场景类型分、按难度分、按风险等级分。简单场景、中等场景、困难场景各占一定比例高风险场景单独一组重点评估。第四步是持续更新。生产环境在变用户需求在变评估数据集也要跟着更新。我一般每个月review一次数据集把过时的场景替换掉把新出现的场景加进去。6.3 自动评估的几种实用方案自动评估有几种常用方案各有适用场景基于规则的评估适合有明确规则的场景。比如检查输出是否包含敏感词、是否超过长度限制、是否符合格式要求。规则评估快、准、便宜但只能覆盖表面问题。基于模型的评估用一个更强的模型来评判 Agent 的输出。比如用 GPT-4 级别的模型给 Agent 的回复打分。这种方案灵活能评估语义质量但成本高而且评判模型本身也可能有偏见。基于参考的评估拿 Agent 输出和参考答案对比用 BLEU、ROUGE 这类指标算相似度。适合有标准答案的场景但 Agent 任务很多没有标准答案所以适用范围有限。基于执行的评估让 Agent 的输出在模拟环境里执行看结果对不对。比如代码生成任务跑一下测试用例就知道对不对。这种方案最可靠但需要搭建模拟环境。实际项目里一般是组合使用。规则评估做第一道过滤模型评估做质量打分执行评估做最终验证。6.4 人工评估的组织与校准人工评估的关键是标准化。不同评估者对“好”的定义不一样不校准的话评估结果没法用。我的做法是先制定评估标准文档把每个维度的评分标准写清楚附上正例反例。然后做评估者培训让所有人评同一批样本对比结果讨论分歧直到大家的评分一致性达到可接受水平一般用 Cohens Kappa 系数衡量0.7 以上算合格。评估过程中要定期做校准。每周抽一批样本让所有人评看一致性有没有下降。下降了就重新培训。评估结果要记录评估者 ID方便追溯。人工评估很贵所以要用在刀刃上。我的策略是自动评估发现的可疑样本、高风险场景的样本、新上线的功能这三类必须人工评估。其他场景抽样评估。7. 安全防护Agent 上生产的最后一道门7.1 Prompt 注入与越狱防护Prompt 注入是 Agent 安全的最大威胁之一。用户输入里如果包含恶意指令可能覆盖 Agent 的原始设定让它执行不该执行的操作。防护手段有几层。输入过滤是第一层检测输入里有没有可疑的指令模式比如“忽略之前的指令”“你现在是另一个角色”这类。指令隔离是第二层把用户输入和系统指令用明确的分隔符隔开让模型知道哪些是用户说的、哪些是系统说的。输出检查是第三层Agent 的输出在返回前检查是否符合预期不符合就拦截。但说实话Prompt 注入没有 100% 的防护方案因为模型的理解能力本身就有不确定性。所以除了技术防护还要有架构防护即使 Agent 被注入了它也做不了危险操作因为工具权限、审批流程、状态机约束都在那卡着。这就是为什么前面讲的架构可控性这么重要。7.2 输出内容的安全过滤Agent 的输出可能包含不该包含的内容敏感信息、不当言论、错误引导。输出过滤是最后一道防线。过滤分两类黑名单过滤和语义过滤。黑名单过滤简单直接维护一个敏感词列表命中就拦截。语义过滤用模型判断输出是否违规能覆盖黑名单漏掉的情况但成本高。我的做法是黑名单做第一道快速拦截明显违规的语义过滤做第二道处理边界情况。两道都过了才放行。过滤不通过的输出要么重新生成要么转人工处理不能直接返回给用户。过滤规则要定期更新。新的敏感词、新的违规模式出现后要及时加进去。我一般每两周review一次过滤规则根据实际拦截情况调整。7.3 操作审计与合规留痕生产系统对审计的要求很高。Agent 做了什么操作、什么时间做的、基于什么信息做的、结果如何这些都要有记录。审计日志要包含请求 ID、Agent 实例 ID、用户身份、输入内容、执行链路每步的决策和工具调用、输出内容、耗时、结果状态。日志要持久化存储保留时间根据合规要求定一般至少半年。审计日志的用途不只是事后追责更重要的是事中监控和事后分析。事中监控能发现异常行为及时干预事后分析能发现系统性问题持续优化。留痕还有一个作用是举证。如果 Agent 的操作引发了纠纷完整的审计日志能证明 Agent 的决策过程是合理的或者能定位到问题出在哪一环。7.4 红队测试与对抗演练上线前做红队测试是必须的。找一帮人专门想办法攻击你的 Agent看能不能突破防护。红队测试的重点包括Prompt 注入能不能成功、工具权限能不能绕过、审批流程能不能跳过、输出过滤能不能骗过、审计日志能不能篡改。每个点都要设计具体的攻击场景实际测一遍。测试发现的问题要分级高危的必须修复才能上线中危的限期修复低危的记录跟踪。修复后再测一遍确认问题解决。上线后也要定期做对抗演练。攻击手法在进化防护也要跟着进化。我一般每季度做一次红队演练保持防护的有效性。8. 从 Demo 到生产的落地路线图8.1 分阶段推进的节奏把控Agent 上生产不能一步到位要分阶段推进。我的经验是分四个阶段第一阶段是原型验证目标是跑通核心流程不考虑可控性。这个阶段快速试错验证技术可行性。第二阶段是可控性建设把前面讲的架构、记忆、执行、评估、安全这些补上。这个阶段最耗时但决定了 Agent 能不能上生产。第三阶段是灰度上线先在小范围、低风险场景试运行收集真实数据发现问题。灰度期间人工兜底Agent 出错人工接管。第四阶段是全量上线灰度稳定后逐步扩大范围最终全量。全量后持续监控持续优化。每个阶段的时间根据项目复杂度定一般原型验证 2-4 周可控性建设 4-8 周灰度 2-4 周全量后持续迭代。8.2 上线前的检查清单上线前对照这个清单检查一遍都过了才能上检查项标准是否必须状态机约束所有状态转移已定义无未定义转移必须工具权限所有工具已分类权限配置已生效必须审批流程不可逆操作有审批审批链路通畅必须超时重试所有工具调用有超时和重试策略必须熔断机制关键依赖有熔断熔断阈值合理必须记忆安检记忆写入有过滤和审计必须输出过滤输出有黑名单和语义过滤必须审计日志完整链路记录持久化存储必须监控告警实时监控异常告警必须回滚方案有回滚预案回滚演练通过必须评估数据集覆盖主要场景标注完成建议红队测试高危问题已修复必须8.3 上线后的持续运营上线不是终点是起点。Agent 上线后要持续运营包括日常监控每天看监控 dashboard关注成功率、耗时、异常率这些指标。指标异常及时排查。定期评估每周跑一次评估数据集看 Agent 表现有没有下降。下降了找原因是模型变了、数据变了还是场景变了。记忆维护定期审查记忆库清理过时记忆处理冲突记忆更新永久记忆。规则更新根据实际运行情况更新过滤规则、权限规则、审批规则。版本管理Agent 的 prompt、工具、配置、记忆都要版本化每次变更记录在案能回退。用户反馈收集用户反馈发现 Agent 的不足纳入优化计划。这套运营机制跑起来Agent 才能持续稳定地服务生产系统。9. 一些踩坑之后的真心话做 Agent 项目这几年踩过的坑比写过的代码还多。有几个教训我觉得值得单独拿出来说。第一个教训是不要迷信模型能力。很多人觉得模型够强Agent 就够可靠。实际上模型再强架构不对照样出问题。我见过用最强模型搭的 Agent因为没做状态机约束在复杂场景下绕来绕去绕不出来。也见过用中等模型搭的 Agent因为架构设计得好稳定跑了一年多。模型是发动机架构是底盘底盘不稳发动机再强也白搭。第二个教训是可控性要提前设计不能事后补。很多项目一开始追求快速上线可控性的事“以后再说”。结果就是技术债越欠越多等到真要上生产了发现要改的地方太多改不动了。我的建议是从第一天就把可控性纳入设计哪怕初期实现简单一点但框架要在。第三个教训是评估数据集比模型调优更重要。我见过团队花大量时间调 prompt、换模型但评估数据集就几十条根本测不出问题。后来把评估数据集扩到几千条才发现之前忽略的很多边界情况。数据集是镜子没有镜子你不知道自己长什么样。第四个教训是人工兜底不能省。再好的 Agent 也有出错的时候关键场景必须有人工兜底。我负责的一个项目Agent 自动处理了 95% 的请求剩下 5% 转人工。就是这 5% 的人工兜底挡住了好几次可能引发事故的错误。全自动听起来酷但生产系统要的是稳。第五个教训是安全防护要假设会被攻破。不要假设你的防护是完美的要假设它会被攻破然后设计第二道、第三道防线。纵深防御的思路在 Agent 安全里同样适用。这些教训都是用真金白银换来的希望看到这里的你能少走点弯路。Agent 上生产这件事没有捷径但有一套可循的方法。把可控性做扎实Agent 才能真正从 Demo 走向生产从玩具变成工具。