很多人问我，为什么自己搭的 Agent 跑 demo 的时候特别顺，一上生产就翻车？答案往往不在模型本身，而在模型外面的那一层“壳”。这层壳就是 Harness 工程。我见过太多团队把精力全花在选模型、调 Prompt、搞微调上，结果 Agent 稳定性、成本、可维护性全栽在没做好 Harness 设计上。今天这篇，我就用实际项目里的经验，把 Harness 工程的核心机制、为什么要这么做、以及落地时容易踩的坑，一次说清楚。
这篇文章不是纯理论科普，而是我在多个 Agent 落地项目里反复试错、沉淀出来的实操思路。不管你是刚接触 Agent 开发、准备在生产环境里上 Agent 应用，还是已经在维护一套 Agent 系统但被稳定性困扰，这篇文章里的拆解和教训应该都能帮上忙。我会尽量说人话，把复杂的概念类比成日常事物，让你能直接拿去参考复现。
1. 为什么 Agent 会“飘”：稳定性问题的根源
1.1 大模型的概率性让 Agent 天然不稳定
Agent 的核心是大模型，而大模型本质上是一个概率系统。同样的输入，你让它连续跑十次，可能得到十种不同的回答，而且这十种回答里可能只有六种是符合预期的。这就带来一个致命问题：Agent 不是一个传统意义上“输入-输出”严格可预期的软件系统，而是一个充满随机性的系统。你没法用“测试用例全部通过”来打包票说它一定稳定。
我举个生活例子。你让 ChatGPT 帮你写一封邮件，它每次写得可能大同小异，但都能用。但假设你在 Agent 里让它调用一个天气 API，它这次返回{"city": "北京", "temp": 25}，下次可能就返回{"城市": "北京", "温度": "25摄氏度"}。虽然语义是一样的，但你的代码是死板的，它不知道“温度”和“temp”是同一个东西。这种不确定性就是 Agent 不稳定的第一个根源。
更麻烦的是，大模型的这个概率性会累积。Reasoning 步骤越多，中间环节越多，每步小小的不确定性就会被放大。这就是为什么有些 Agent 任务第一步做得很好，到第三步就开始胡言乱语。你要是不在中间加约束，那 Agent 就是在裸奔。
1.2 工具调用的不可控性
Agent 的核心能力是调用外部工具，比如搜索引擎、数据库、内部 API、代码解释器等。但外部工具本身也是不稳定因素。搜索引擎可能暂时连不上，数据库可能查询超时，API 可能改了返回格式。如果 Agent 直接裸调这些工具，它就得自己处理各种异常情况，而大模型又不擅长处理异常，它更擅长“编一个看似合理的假响应”。
我在生产环境里见过最典型的翻车：Agent 调用内部订单查询接口，接口因为网络原因超时了，但 Agent 没有收到明确的错误码，于是它自动“脑补”了一个订单状态。用户看到的是一个正常的界面，但那个订单状态是虚构的。这种问题就是典型的稳定性灾难，它不是模型能力不够，而是工具调用这层没做好防护。
工具调用的不可控性还包括“工具太多导致选择困难”。如果你给 Agent 挂了 20 个工具，它可能不知道该选哪个，可能选了个次优的，可能选了之后又后悔，来回切换工具反复调用——工具调用的次数上去了，Token 成本和延迟也同时上去了。
1.3 状态与上下文的污染
Agent 在多轮对话或长期任务中，会不断累积上下文。上下文一长，问题就来了：中间结论错误但后续步骤没有重新校验、无关的旧信息干扰新决策、对话历史里的小错误被越滚越大。这就像团队里来了一个记性特别好但有点糊涂的同事，他把所有垃圾信息都记在脑子里，最后做决策时不知道该信哪条。
上下文污染在 Agent 里具体表现为：多轮对话后 Agent 把用户刚才说的 A 事，和 20 轮之前说的 B 事混在一起；或者在执行一个多步骤任务时，它把第一步失败的结果，当成成功的结果继续往下走。这些问题的本质，是 Agent 缺乏一个“记忆管理”机制，什么东西该记、记多久、什么时候应该遗忘和更新，完全没有规划。
2. Harness 工程到底是什么：核心机制拆解
2.1 从“模型裸奔”到“模型带护栏”
所谓 Harness，中文可以理解成“拴马索”或“控制带”。它的核心思想，是把模型当作一个“带护栏的引擎”，而不是一个“自由的灵魂”。你可以把大模型想象成一个能力很强的实习生，聪明、有创意、执行力强，但他经验不足、容易跑偏、输出还不稳定。Harness 工程就是给他配一套作业流程和质检体系：明确他每一步要做什么、输出格式是什么、出了问题怎么上报、哪些事情绝对不能碰。
Harness 工程并没有一个标准化的官方定义，比如像 HTTP 协议那样有 RFC 文档。但它已经成为 Agent 工程化实践中公认的一种“最佳实践集合”。在社区里，它通常包含状态追踪、工具调用治理、上下文管理、错误恢复、可观测性、成本控制这几个核心模块。说白了，就是给 Agent 画上一套完整的“筋斗云驾驶舱”，而不是让它自己云里雾里乱翻跟头。
我习惯把它类比成汽车的“动力总成”和“车身控制”。模型是发动机，提供动力；Harness 是变速箱、转向、刹车和仪表盘。你不能只有发动机就上路，必须有控制方向和速度的工具，还要有仪表盘监控转速和油量。Harness 工程就是这套“车身控制系统”。
2.2 核心机制一：外部确定性约束
大模型天生是概率性的，但我们的业务系统要求确定性。这两者的矛盾怎么解决？答案是：用确定性去约束不确定性。也就是说，我不让模型自由发挥，而是严格定义它能说的“语言”。
比如在工具调用上，我不允许模型自己“发明”一个 JSON 格式出来。我会在后端定义一个严格的工具调用协议，要求模型的输出必须是符合 JSON Schema 的结构。这个 Schema 里定义了每个参数的名称、类型、取值范围、是否必填。模型输出后，我先做校验，不通过就重新请求模型或者报错退出——绝不让脏数据进入业务流程。
再比如“人机交互流程”，很多 Agent 框架允许模型自由决定是否要追问用户。但在 Harness 工程里，我会定义明确的“追问机制”：什么时候可以追问、追问必须包含哪些信息、追问的上限是多少次。这样用户不会被同一个 Agent 连续询问五次同一个问题，不会觉得“这个 AI 是不是傻”。
2.3 核心机制二：可观测性与全链路追踪
传统后端系统的问题排查已经非常成熟了，有日志、有指标、有追踪。Agent 系统呢？很多团队做出来就是个黑盒：模型内部怎么推理的看不到，调了哪些工具看不到，为什么选了 A 而不是 B 也不知道。出了问题只能重新跑一遍，但概率性决定了重跑很可能复现不了同样的问题。
Harness 工程里，可观测性是刚需。你必须在每个关键步骤埋点：
- 用户输入是什么，模型收到的是什么；
- 模型推理结果是什么，是继续思考、发起工具调用还是直接回复用户；
- 工具调用发起时传的参数是什么，调用结果是什么，耗时多少；
- 最终回复用户的内容是由哪一次推理生成的，中间经过了几轮工具调用。
这些信息最好全部结构化输出，方便后续做分析和回放。我在实际项目里，会把每次 Agent 执行完整会话都生成一个 trace ID，然后把每一步的输入输出记录到日志系统。出了问题，直接按 trace ID 拉出完整时间线，一眼就能看到哪一步开始跑偏的。
2.4 核心机制三：受控的失败兜底
Agent 在实际运行中一定会遇到失败：工具超时、模型返回格式不合法、上下文超出限制、用户输入了范围外的合法请求。这些失败如果靠模型自己硬扛，那大概率会得到“一本正经的胡说八道”。所以 Harness 工程里要有明确的失败路径设计。
我常用的是“三层兜底法”：
- 第一层，重试机制。工具调用超时，我可以快速重试一次，因为很多超时是暂时性网络抖动；
- 第二层，降级替代。如果重试还是失败，我可以用规则引擎替代模型处理，比如直接返回一个固定话术，让用户稍后再试，或者引导用户换一种表达方式；
- 第三层，人工转接。如果 Agent 已经尝试了多次依旧失败，那就别逞强了，直接走人工客服或通知维护人员介入。这个“认怂机制”非常重要，因为很多业务场景中，客户等不起 AI 反复试错。
失败兜底的核心原则是“宁可承认失败，不可假装成功”。我见过太多 Agent 设计成永不认错，最后编出假数据，那才是真正的灾难。
3. 落地实操：搭建稳定 Agent 的五个关键环节
3.1 工具调用治理：从“自由发挥”到“严格白名单”
工具调用的不稳定，很大程度上是因为模型对工具的“理解”有偏差。你需要做两件事：一是工具数量不要贪多，二是每个工具的签名和描述写得极其明确。
我给工具描述定了一个原则：描述里要写清楚“什么时候该用这个工具”“什么时候不该用”“参数应该怎么传”。很多时候模型选错工具，不是模型笨，是工具描述太模糊。比如你写“查询用户信息”，模型可能以为这个工具能查所有用户，但实际上它可能只能查当前登录用户。你必须在描述里写明“仅用于查询当前会话用户的详细信息，不可查询其他用户”。
在工具选择策略上，当工具数量超过 10 个时，强烈建议引入“工具分组”或“两阶段路由”。先用一个轻量级分类模型，判断用户请求属于哪个领域（比如订单、售后、客服），然后再把对应领域的少数几个工具传给主模型。这样大大减少了模型的选择困难，也降低了上下文里塞入过多工具定义导致的 Token 开销。
工具调用还有一个关键点：超时。每个工具都应该有独立的超时设置，不能一把尺子量到底。比如查询缓存的工具可以设 1 秒超时，查询数据库的工具可以设 5 秒超时，内部 API 可以设 3 秒超时。超时上限要硬编码，不能让模型自己决定是否等待。我在项目里见过最离谱的事，Agent 调用一个挂掉的接口，居然等了 8 分钟才放弃，用户早就关掉页面了。
3.2 上下文管理：记忆的设计与更新策略
上下文是 Agent 的命脉，也是最大坑。我常用的上下文管理策略是分层：
- 核心层：用户当前请求、必要的业务状态。这个必须保留，不能丢；
- 工作记忆层：当前任务产生的中间结果、工具调用记录。保留最近 N 轮即可；
- 长期记忆层：用户偏好、历史对话摘要。可以存到外部向量数据库，按需召回；
- 噪音层：一些无关紧要的闲聊、错误尝试，直接从上下文里删除。
在具体操作上，我建议用“滑窗+摘要”组合。滑窗保留最近 K 轮的完整对话，更早的内容用一个大模型做一轮“摘要压缩”，把关键信息提取出来放到上下文最前面。这样长对话场景下，既保留关键信息，又不会让上下文指数膨胀。
另一个重要机制是“结论校验”。如果 Agent 在多个工具调用中累积了一个中间结论，在最终生成结果前，最好让它重新审视一遍：“根据以上信息和工具调用结果，我的结论是否仍然成立？”这一步不是多余的，它在复杂任务里能显著减少“上下文污染导致最终结论错误”的概率。用我自己的经验来说，加上这轮校验后，长任务的准确率能提升大概 5 到 8 个百分点，代价只是多付一次推理的 Token 钱，值。
3.3 Token 成本与延迟控制
Token 是 Agent 的第二大成本，也是稳定性问题。我要说个真相：很多 Agent 不稳定，不是模型不行，是业务方舍不得花 Token 做校验和重试，导致错误一路滚到最终结果。
Token 开销大头通常不在回复本身，而在工具定义、系统指令和上下文累积。工具定义动不动就几千 Token，系统指令再写个一两千，上下文再来几轮历史，一次请求轻松破万 Token。长期跑下来，成本非常可怕。
我常用的压缩手段有：
- 精简工具描述，只保留必要信息；
- 上下文里历史对话做向量化压缩，不直接堆原文；
- 系统指令模板化，避免每次请求都传一堆重复内容；
- 对于步骤简单的任务，使用更小更便宜的模型，把大模型留给复杂推理。
关于延迟，一条铁律：不要让 Agent 在关键路径上串行调用太多次模型。如果某个任务需要连续调用 5 次模型，那你得考虑能否用“规则+少量模型调用”替代。我见过一个 Agent 任务本来只需要调用一次模型就能完成，但流程设计不当，导致模型被反复调用 9 次，耗时暴增到 30 秒，用户根本无法接受。
3.4 结构化输出的强校验
Agent 的稳定性，很大程度上取决于你是否用了“强校验”。大模型的输出你可能看着没问题，但程序面前全是坑。比如模型返回了一个 JSON，但多了个逗号；返回了一个字符串，但多了一行解释性文字。
我强烈建议所有模型输出都走“结构化解析 + 校验”流水线，而不是直接相信模型输出。常见的做法是：先用 JSON Schema 校验，不合法就利用模型本身纠错能力，把错误信息反馈给模型让它重新生成。有些框架支持 function calling，它会在模型层帮你约束输出格式，但仍然建议自己在应用层再加一道校验，因为 function calling 也不是 100% 保证合法。
还有一个小技巧：在系统指令里明确告诉模型“不要输出任何与 JSON 无关的解释文本，不要用 Markdown 代码块包裹 JSON”，这能大幅降低解析失败率。但如果只是加指令，模型有时还是会犯，所以校验逻辑必须放在代码层面，而不是依赖模型的自觉。
3.5 状态机驱动：让 Agent 有明确执行路径
如果你让我在产品里选一个“最重要”的 Harness 机制，我选状态机。Agent 不应该是一个“自由奔跑的思维体”，而应该是在一张“有向图”里移动的个体。每个节点代表一个状态，每条边代表一次转移，每个状态里定义允许做哪些操作。
拿一个电商售后 Agent 举例：
- 状态一，收集问题类型；
- 状态二，核实订单有效性；
- 状态三，判断是否符合退换货条件；
- 状态四，执行退款或换货流程；
- 状态五，确认售后结果。
在这种设计下，Agent 不能从“收集问题类型”跳到最后一步“执行退款”，它必须按照状态机规定的路径走。这大大约束了模型的自由度，确保关键业务步骤不会被跳过。谁要是没设计状态机就敢上生产 Agent，我只能说是勇士。
4. 部署架构与工程化经验
4.1 主流 Agent 架构模式对比
现在做 Agent 的框架很多，但我发现很多人只关注某一套框架的 API，忽略了架构层面的选择。目前主流的 Agent 架构模式大概有三种：
- 单 Agent 模式，所有能力集中在一个 Agent 上，适合简单任务，开发和维护成本低，但扩展性差；
- 多 Agent 协作模式，多个 Agent 各司其职，通过消息或任务队列协作，适合复杂业务，但对 Agent 之间的交互设计要求高；
- 人机协同模式，Agent 负责辅助和推荐，关键决策由人来做，适合高风险场景如医疗诊断、金融交易。
从稳定性的优先级来排序，我的经验是：人机协同 > 单 Agent 模式 > 多 Agent 协作模式。这不是说多 Agent 不好，而是多 Agent 协作的复杂度会让稳定性指数级下降。如果你对稳定性要求极高，但业务复杂度还没到必须多 Agent 的程度，那单 Agent + 状态机往往是性价比最高的选择。 另外，多 Agent 交流时的“转述”会造成信息损耗。Agent A 给 Agent B 传一个指令，Agent B 理解偏了，再传给 Agent C，可能已经面目全非。这种错误很难直接定位，排查成本极高。所以我要给个比较中肯的建议：能用单 Agent 解决的，别硬拆成多 Agent；必须多 Agent 协作时，尽量通过结构化协议（比如固定 JSON schema）而不是自然语言传讯，减少理解偏差。
4.2 部署形态：云原生与独立服务
部署上，我建议把 Agent 服务作为一个独立的微服务来治理，而不是把它塞进现有业务系统的一个函数里。独立部署的好处是：
- 可以独立扩缩容，比如大模型调用高峰期单独扩容，不影响其他业务；
- 可以独立监控，Agent 的日志和指标与核心业务解耦，避免日志互相干扰；
- 可以独立发布，Agent 的 Prompt 或工具逻辑改版频率比核心业务高得多，独立发布可以避免频繁发版核心系统。
在资源分配上，要特别注意“并发控制”。大模型 API 通常有速率限制，如果你不加本地限流，而是直接把前端请求转发给模型接口，那结果一定是不稳定的。我习惯在 Agent 服务前面加一层本地限流队列，控制每秒请求数，超出的请求排队等待，而不是直接打挂模型 API。
另外我强烈建议，如果业务量上来了，尽早把模型 API 代理层做掉。也就是说，你的服务不直接调第三方模型的公开接口，而是走自己封装的一层代理。这层代理可以帮你做：请求重试、超时控制、多模型路由切换（比如 A 供应商挂了自动切换 B）、统一的日志审计。代理层的成本极低，收益极高。
4.3 语言选型与生态适配
社区里关于“用 Rust 写 Agent”的讨论很火。我不否认 Rust 在并发和安全上的优势，但我想说一个老实话：Agent 项目的逻辑复杂度主要在前端交互、状态管理、业务编排和生态连接上。这些领域，Python 和 TypeScript 的生态成熟度远高于 Rust。当你需要快速接一个向量数据库、连一个微信机器人、调试一段 Pandas 逻辑时，Python 的优势是非常明显的。
当然，如果你确实追求极端性能，比如高并发、低延迟的 Agent 网关，那 Rust 做底层网关是非常合适的。我记得之前调研过一些开源项目，核心的调度和路由单元用 Rust 实现，而上层业务编排仍用 Python 或 TypeScript。这算是一种比较合理的折中方案。
我个人的建议是：中小型项目和业务落地场景，优先选 Python 或 TypeScript。Rust 可以作为基础网关层选型，但不建议所有 Agent 逻辑都用 Rust 重构一遍，除非你有一个专门的基础设施团队来维护。
4.4 可观测性落地：日志、指标、追踪三板斧
可观测性在 Agent 系统里怎么落地，很多人一头雾水。我的经验是，先在代码层做好三件事：
- 日志：每个 Agent 执行会话记一条 JSON 日志，包含 trace ID、状态流转、每一步耗时、模型输入输出摘要；
- 指标：统计工具调用成功率、模型调用延迟、token 消耗量、状态机转移次数、用户重试率；
- 追踪：链路追踪可以借助 OpenTelemetry 之类的全家桶，把一次用户请求从入口到模型调用再到工具调用的全链路串起来。
我这几年踩坑最多的就是在“哪个环节出了问题”上。有了这三板斧，你至少能快速定位：
- 是模型推理的问题（看模型输出摘要）；
- 是工具的问题（看工具调用记录和返回值）；
- 还是上下文的问题（看上下文历史和摘要压缩结果）。
5. 常见问题与排查技巧实录
5.1 问题一：Agent 调用工具时返回格式总是解析失败
这是一个几乎所有人都会遇到的问题。现象是，模型“看起来”调用了正确的工具，返回的 JSON 格式也“看起来”对，但程序解析时总是报错。排查思路：
- 先看是不是模型返回里带了 Markdown 代码块标记。很多模型会把 JSON 包在一个
json代码块里，你的解析器如果没处理这个，就会失败。解决方案是在解析前先做一次清洗。 - 再看是不是模型在 JSON 末尾加了解释性文字。解决办法是在系统指令里强调“仅输出 JSON”，同时在解析时采取“截取第一段合法 JSON”的策略。
- 最后看是否是 JSON Schema 定义过于复杂，导致模型总是漏填字段。解决办法是尽量简化 Schema，去掉非必要字段，把必填字段降到最低。
我实测下来，最有效的方案是最底层做一个“宽容解析器”，它能从模型回复中提取第一段合法的 JSON 片段，再交给严格校验层。宽容解析保证不崩，严格校验保证不脏，两段结合反而比单纯依赖某一种更稳。
5.2 问题二：多轮对话中，Agent 把历史错误当成事实
这种问题的典型表现是：第一轮用户说“帮我查一下 D 公司的订单”，Agent 查错了公司；第二轮用户说“换个公司查”，Agent 回答时仍然带着第一轮的错误结论。这是上下文污染的后遗症。
我的排查和修复方法：
- 首先，检查上下文历史里是否存了错误中间结论。如果存了，就要在进入下一步前加入“状态校正”机制，让模型重新评估当前状态；
- 其次，对关键字段做一个“记忆覆盖”。当新信息明确覆盖旧信息时，例如用户说“其实是 E 公司不是 D 公司”，要在上下文里显式地写入一条“用户更正：D 公司改为 E 公司”，而不是让模型自己去推理；
- 最后，对高风险领域，可以考虑把上下文重置或分段，在每一段开始时重新输入业务状态快照，避免历史认知污染新决策。
5.3 问题三：Agent 在工具调用循环里出不来
你有没有见过 Agent 反复调用同一个工具，每次都返回“数据不足”，然后它就再调一次，甚至连续调用十几遍？这通常是因为 Agent 缺少“退出条件”。它可能不确定自己该在什么条件下停止搜索新数据，于是陷入无限循环。
解决方案有两个层面：
- 第一，在系统指令里明确写清楚“如果你已经获得了足够信息，请停止调用工具并给出最终回答”；
- 第二，在代码层面设置硬性调用次数上限，例如累计调用 5 次还没完成，就强制结束工具循环，启动降级逻辑。
这两者缺一不可，因为只靠指令约束并不可靠，模型可能会忘记。只靠代码限制，又可能误伤一些确实需要更多工具调用的复杂任务。硬上限设得合适，比如 8 到 10 次，基本能兼顾两种情况。
5.4 常见问题速查表
我也整理了一个迷你速查表，方便你在排查时对照：
| 症状 | 可能原因 | 优先排查项 |
|---|---|---|
| 输出格式解析失败 | 模型返回被 Markdown 包裹或带解释文字 | 清洗逻辑是否覆盖代码块；系统指令是否明确 |
| 多轮对话历史错乱 | 上下文污染、旧结论未覆盖 | 状态校正机制是否开启；关键字段是否显式更新 |
| 工具调用循环 | 缺少退出条件或硬性上限 | 是否设置最大调用次数；退出条件是否在指令中 |
| Token 消耗过高 | 上下文累积、工具定义过多 | 是否使用摘要压缩；是否精简工具描述 |
| 延迟过高 | 串行调用模型次数过多 | 是否能用规则替代部分模型调用；是否走代理缓存 |
| Agent 给出错误工具结果 | 工具描述模糊 | 工具描述是否写明边界和使用时机 |
6. 场景延伸：从技术到业务的落地思考
6.1 用状态机思路做“小红书自动发消息”这类场景
最近很多人问“用 AI Agent 让小红书自动发消息”这事儿怎么做。我觉得这正好能印证 Harness 工程的价值。这类型任务看起来简单，但直接让模型拿账号去发内容，一定会翻车。为什么？因为评论和消息场景高度依赖上下文、语境和平台规则。如果模型看到一条负面评论，它可能回复得过于强硬，导致账号风险；如果看到一条推广消息，它可能直接点击了里面的链接，导致安全问题。
正确做法是设计一个“内容审核 + 回复生成”的状态机：
- 状态一，接收新消息；
- 状态二，做情感分析和风险识别；
- 状态三，若风险较低，生成回复初稿；
- 状态四，走一遍回复审核规则；
- 状态五，审核通过后再执行发送。
这套状态机不仅控制了模型的行为边界，还保证了关键操作（发送）必须经过一个可追踪、可回滚的流程。这比“模型直接调用发送函数”稳定得多。
6.2 基于 Django 的 Agent 业务流程集成
如果你用 Django 开发业务系统，要把 Agent 集成进去，我最想提醒的是“不要把 Agent 逻辑和 Web 请求强耦合”。Web 请求有明确的超时预期，用户等不了 30 秒，但 Agent 常有长任务，可能在后台跑好几个来回。我的建议是：Web 层面只负责接受请求和返回“任务已受理”的凭证；真正的 Agent 执行放到异步队列里，例如 Celery 或者独立的 Worker，用 WebSocket 通知前端执行进度。
这种“异步 + 任务化”的架构，既保护了 Web 服务的稳定性，也让 Agent 有了充足的时间窗口去执行工具调用和模型推理。你会发现，用户体验反而更好，因为页面可以实时展示“正在查订单”“正在生成回复”等中间过程，而不是白屏等待。
6.3 Agent 白皮书里的关键共识
最近业内有一些机构发布了 Agent 的白皮书，里面有几个共识我认为特别值得强调：
- Agent 的稳定性不是靠模型一个环节解决的，而是系统工程；
- 上下文管理和状态追踪是当前工程落地最被低估的环节；
- 可观测性的重要度被很多人排在功能之后，其实它应该是第一位；
- 工具调用是 Agent 的“高风险区”，占比不算高但事故率最高。
这些共识其实和我实际踩坑的经验高度一致。如果你正处在“Agent 怎么从 demo 走向生产”的阶段，建议你把注意力从“怎么调 Prompt”转移到“怎么设计可观测、可回滚、可控的流程”上来。把底座打好，上层模型的调优才有意义。
7. Agent 规模化的未来挑战与我的个人体会
7.1 评估集与回归测试：稳定性不能靠感觉
很多团队在评估 Agent 时，喜欢用几个手写 case 跑一遍，看看行不行。这是远远不够的。Agent 是概率系统，单次通过不等于稳定。我建议一定要建立评估集，至少几百条覆盖不同场景的输入-输出对。每次迭代 Prompt 或工具定义，都要用这个评估集跑一遍回归，统计通过率的变化。没有这种量化手段，你根本不知道这次改动到底是让 Agent 更稳定还是更脆了。
评估集还可以配合“高稳定区”和“低稳定区”做分层分析。例如，简单闲聊场景应该 100% 稳定；中等工具调用场景可以接受 90% 以上；复杂推理场景可以放宽到 80%。有了分层指标，你就知道该把优化资源花在哪个薄弱环节上。
7.2 从模型能力到工程治理的重心转移
很多人迷信“换一个更聪明的模型，一切问题迎刃而解”。我不否认强模型能掩盖很多问题，但掩盖不等于解决。模型再聪明，你让它在一个没有状态管理、没有错误恢复、没有可观测的系统里干活，它一样会搞砸。就好比给一个天才程序员一台没有显示屏、没有键盘、没有电源的电脑，他什么都写不出来。
我的观点是，模型能力决定 Agent 的能力天花板，但 Harness 工程决定 Agent 的能力地板。而用户感受到的稳定性，更多接近“地板”而不是“天花板”。与其反复琢磨换模型，不如先把 Harness 这层地板抬高。
7.3 一个被低估的机制：让 Agent “知道自己不知道”
在真实的业务系统里，稳定性的很大一部分来自“谦逊”。什么意思？就是让模型明确知道：哪些问题是它能解决的，哪些是它不能解决的。一旦问题落到能力边界之外，就应该明确说“我不知道”或者“需要人工介入”，而不是硬着头皮给一个错误答案。
在设计上，我会专门在状态机里加一个“边界检查”节点，通过意图识别，判断当前用户请求是否在可用工具和知识范围内。如果不在，直接走“澄清引导”或“人工转接”路径，绝不进入主流程。这个机制对“稳定”的贡献，很多时候比提升模型的推理能力还大。
7.4 最后分享一个我的习惯
好的架构都不复杂，把模型当员工、Harness 当制度，制度和流程稳定了，员工的天赋才能稳定发挥。
我最后再分享一个小习惯：每次调试 Agent 不稳定问题，我都会先看 trace 日志，再看评估集回归结果，绝不直接去改 Prompt。这个习惯帮我省下了大量无谓的调试时间。你会发现，很多所谓的不稳定问题，根本不是 Prompt 写得不好，而是工具超时没兜底、状态没管理、失败路径没设计。把这块补上，你会发现你的 Agent 突然就“稳”了。
