在 AI 编程助手赛道持续升温的当下，模型层的能力跃迁几乎以周为单位迭代——从 Claude Opus 到 GLM、Kimi、MiniMax 再到 GPT 系列，新模型密集发布已成为常态。然而对于构建上层 Agent 应用的团队而言，模型能力的剧烈变化恰恰构成了最大的架构挑战。
以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。
近期北京天气变化剧烈，前两日阴雨绵绵，今日气温却已飙升至二十余度，因未能及时增减衣物而不慎感冒。这件事让我联想到一个颇为贴切的行业现象。这一周 Claude 发布了新模型 Opus，再往前数周，智谱的 GLM、Kimi、MiniMax 以及 GPT 等各类模型接续发布，密集程度堪比天气变化。Comate 是做上层应用的团队，并不训练模型。然而如果应用层不能有效适配模型的快速变化，同样会“感冒”——Comate 曾经就经历过这样的困境。
因此，当我们不去训练模型，而是选择构建 Agent 的时候，如何有效适配这些模型的变化，如何让 Agent 框架和 Agent 产品在面对模型能力跃迁时保持弹性，面向未来做架构设计，就构成了本次分享的核心命题。我们将从 Feedback Loop、Benchmark 以及 Agent Engineers 三个方向展开。这不是一套空洞的方法论，而是来自一线实践的压箱底干货。
先看这套方法论在百度内部落地的实际成效。以横轴表示百度全员中适合使用 Agent 的非开发者和开发者的每周使用 Query 次数作为衡量指标——所谓一次 Agent Query，即用户写一个 Prompt 让 Agent 帮忙完成一件事。数据显示，Query 数量的增长曲线在某一个时间点出现了极为陡峭的爬升。截至三月底的数据表明，百度员工在使用 Agent 时，每周人均 Query 次数已达到九十余次，意味着一周之内发出了将近一百次任务请求，每一个 Query 都代表了一个被委托给 Agent 的任务。我们之所以选择人均 Query 数而非 Token 消耗量作为衡量指标，原因在于 Query 本身能更精确地映射出 Agent 实际完成的任务数量，而 Token 数量则很难直接反映完成了多少任务以及提效的具体幅度。
与此同步发生的还有另一个变化。Comate 拥有自己的 IDE，类似于 Cursor 的体验，也提供 JetBrains 插件和 VS Code 插件。我们越来越发现，更多用户选择直接使用 Comate IDE，放弃 JetBrains 和 VS Code。他们不单单在里面写代码，编译和调试等工作也一并迁移了过来。与此同时，使用者的角色边界也在被打破。产品经理尚属研发圈子，但令人始料未及的是，售前工程师和销售人员竟然也开始使用 Agent，用来分析数据、做项目管理，这一现象完全超出了我们最初的预期。
这些用户在用 Agent 做什么？本质上都可以归入 Vibe Coding 的范畴，但具体可以划分为两个截然不同的类型。
第一类场景是非开发者解决那些“大量可以用研发能力解决，但永远不会被纳入研发排期”的工作。一个典型的例子是产品经理的数据统计诉求。过去，产品经理需要找到研发同事，请求帮忙写一条 SQL 到数据库里查询过去一周的日活和留存数据，研发还需要担心查询数量过大可能导致锁表。而现在，我们直接让产品经理拿着 Agent 连接数据库，配一个只读账号即可自行完成查询。这类需求优先级不高，但始终存在，产品经理通过 Agent 立刻就能满足。
这里可以引入一个颇具启发性的类比。当前俄乌战场上无人机的使用方式呈现出一种非常有意思的特点。假设战场上发现十公里外有两名敌人，车辆无法靠近，枪械也打不到。此时如果要调动炮兵，需要请示师长级别才能做出决策，整条决策链路相当漫长，等到审批完成敌人早已离开。更严重的是，即使决策链路完成了，一发炮弹打出去，炮兵阵地也随之暴露，对手很有可能就是拿这两名士兵做诱饵，旨在吸引你的炮兵暴露位置。放在研发层面上，这完全是一个逻辑自洽的隐喻。当我们真正要去实现一个 Feature 的时候，需要调动大量研发精力和团队协作，耗费海量资源。等我们做出来，很可能这个产品或者这个 Feature 已经不复存在，已经错过了窗口期。Agent 的出现在很大程度上解决了这类问题——它没有将决策链条拉得过长，也不需要耗费整建制的研发资源。
第二类场景是真正的严肃开发，即我们日常的软件迭代。放在三个月前，即便在团队内部讨论时，我也认为 Vibe Coding 在这类场景上不靠谱，只能覆盖第一种类型的需求，第二种做不了。但现在情况已经完全不同了。包括 Comate 研发团队自身，也在大量使用 Agent 来生成 Agent。一个根本性的变化在于，开发者个人从执行者变成了问题的提出者。我们越来越发现，制约效率的瓶颈已不再是 Token 价格是否昂贵，而在于一个人能不能提出一个好问题，去让 Agent 帮我们实现它。在面向研发团队的变化中，另一个趋势同样显著。我们正在推进全栈，但这种全栈并非传统意义上的“Java 工程师因为有了 Agent 就可以写 Python 了”，不是编程语言层面的全栈。我们所理解的全栈，是角色维度的全栈——集产品经理的 Sense、交互视觉的 Sense 以及构建测试边界的 Sense 于一身。正是这样的全栈能力，才能充分激发 Agent 的能力。
在这种全栈的驱动下，越来越多的大型 Feature 被拆解为小型 Tasks。过去需要多人并行执行的任务，现在反而倾向于直接交由一个人搭配 Agent 把整个事项全部完成——效率更高，质量也更优。
进一步细化这些 Query 的类别，我们可以从百度一周的数据来看。整体可以归入几个大类，其中有三类体量最大。第一类是 Code Exploration，即代码探索，包括代码检索和代码解释——让 Agent 帮忙解释问题、探索代码库、做技术调研等。这一类占比几乎最高，接近百分之二十。大量的人在使用 Agent 获取信息。第二类是 Debug，即排查错误，每天把日志提供给 Agent，请它帮助定位问题。第三类才是实现新 Feature。这一分布完全符合工程师的直觉：每天我们真正在做的事情并不是实现新功能，而是研究和排查问题。
基于这些线上数据，Comate 正在搭建的 Agent 框架采用了两层 Loop 的设计。这一结构我们当初构思出来时觉得格外精妙。中间层 Loop 由工具、环境和模型三者构成最基本的 Agent 闭环框架。外围第二层 Loop 则赋予 Agent 更多手脚去探索外部环境，包含记忆（Memory）、技能（Skill）、规则（Rules）、MCP 以及 Agents 本身——即所谓的边界条件。前段时间 Claude Code 源码泄露的时候，相信在座有老师已经注意到，源码里面大量的边界条件处理令人难以想象其复杂度。Comate 并不训练模型，因此在最初构建 Agent 框架时，我们的策略相对谨慎：当模型输出出现问题或者流程不对时，我们不急于去修，而是等待模型自身完成升级。但我们发现 Claude Code 源码的做法并非如此，他们作为自家产品，竟然有大量代码在专门处理边界条件，充斥着各式各样的 if-else 逻辑。由此我们重新看待 Harness 这个概念。Harness 是一个更大的范畴，它指的是帮助 Agent 完成各种脏活累活、将各种边界条件限定好的那一层工程设施。
这套框架提出来之后，我们自己构建 Agent 时也觉得相当不错。但问题来了：当新的模型大量推出的时候，Comate 这个框架着实“感冒”了。第一个问题的根源是模型能力的变化，以 DeepSeek 刚推出时为例，当时它有一个硬伤，对 Function Calling 支持得很不好，但对 XML 是 OK 的。因此那时我们去构建 Agent 框架，包括社区中很多 Agent 框架，都走了 XML 路线而非 Function Calling 路线，我们也不例外。但到了去年下半年，各个模型对 Function Calling 的支持已经非常成熟，此时原来的框架就跟不上了。框架的运转在旧有的逻辑体系里是自洽的，但在新模型下功能变得不可用。这揭示了一个根本性问题：随着模型解题能力越来越强，我们必须动态调整框架，根本不存在一个可以完全确定的静态框架。另一个例子是 Spec Driven，前几个月关于 Spec Driven 的讨论相当热烈，但如今已经没有多少人再去过多考虑这个问题了，因为模型解析能力实在太强了，Spec 所驱动的那些细节已经不需要人再去关注，不需要再手把手拆解各种任务，只要把事情写成一个 Query、做好澄清、做一个计划然后去执行就够了。
要有效观测这类变化，我们必须构建有效的评测集。此前在跑 SWE-bench、SWE-bench Pro 这些评测的时候，我们更多关注的是分数。但我们越来越发现，分数本身并不重要，重要的是那些异常值。同样的一个分数，上一次跑评测时做对的题可能是那六十道，下一次跑的时候分数一模一样，但对的那部分题很可能是另外六十道——对的题换了一组，分数保持不变。因此只关注分数毫无意义，必须去发现那些异常情况。
Comate 是怎么解决这些问题的？首要的就是构建 Feedback Loop，让 Agent 的行为和观测结果形成反馈闭环。Agent 被推送到线上供用户使用后，会产生大量的线上数据。在确保安全、不泄露用户隐私的前提下，关键在于怎么关注这些数据，让 Loop 更好地运转，让飞轮转起来。我们认为应该统计四类数据，从最上层最直观的到最下层最复杂的递次展开。
第一层是工具层。类似的数据指标相信大多数构建 Coding Agent 的老师都会有统计：工具的调用次数、失败率、失败后的自愈比例，以及 Query 与 Tool Call 的比例。Query 与 Tool Call 的比例这个指标至关重要，它衡量的是一个 Agent 在最终解决问题的时候，需要通过多少轮次才能把事情完成。观察所有这些数据时，都必须按照模型来做区分。我们以 Claude 为标杆，同时跑 Kimi、GLM、文心等模型，对比 Claude 在完成同类任务时的 Query 与 Tool Call 比例，再看 GLM、Kimi 和文心的数据分别是怎样的。如果比例出现异常，就能指明差距究竟在哪里，我们就按照 Claude 的数据作为基准来做对比分析。
第二层是上下文层。这块大家可能比较关注的有 Skill 的唤起、Memory 的唤起等。
第三层是执行结果。这一层有一个我们标注为红圈的数据尤为有趣。当一个 Agent 创建任务并创建了一个文件之后，创建完又反复调用好几次工具去不断修改这个文件——这一行为就能反馈出一个问题：说明 Agent 第一次创建文件时根本没有分析好，在前面做问题澄清的阶段就没想清楚，导致后续需要大量的修补操作。这个信号反过来推动我们去审视 Agent 的执行轨迹是否存在问题。
第四层是最难的，即如何有效衡量一个 Query 从发出直到 Agent 最终将整个任务执行完毕，其执行轨迹是否优良。目前我们只是抽象出了几个类别，这一层仍在建设之中，确实尚不清楚确切的标准，只能抛出一个引子供大家探索。
在上述几层观测中，有几个实践值得深入分享。
第一个实践发生在第二层上下文层的监控之中，让我们看到了 MCP 和 Skill 在 Token 消耗上的对比极为强烈。Skill 是在去年十月底推出的，其核心思路是渐进式发现，无论从效果还是 Token 消耗角度都是更优选。作为对比，MCP 则是非常反向的例子，假设有三个 MCP Server，每个 MCP Server 各自有十个工具，我们以类似 Function Calling 的方式把这些工具全部传进去，结果一下子就把上下文给冲爆了——这完全不再是渐进式了。
这一发现促使我们思考：Skill 的渐进式思路能不能应用到 MCP 上？Skill 和 MCP 肯定不是非此即彼的关系，Claude 也是同样的判断，两者各有长处，我们不能完全用 Skill 来替代 MCP。那么能否找到某种方式，让 MCP 也能以渐进式的方式帮助节省 Token，同时保障上下文的效果不至于恶化？我们为此做了一件事：让 Comate 自动为每一个 MCP 生成一个类似于 Skill 的描述。然后我们在 Agent 内置了一个 Skill 工具，在这个工具里面定义了几个关键变量，Tool Name 即工具名称 ，Tool Description 即工具描述。我们在这个描述里面仿照加载 Skill 的方式，把 MCP 的内容加载进去。最终开发者在使用的过程中，即使有十个 MCP 或三个 MCP，他看到的只有一个工具。这个工具的描述会告诉他：我现在有三个 MCP。当 Agent 真正需要使用某个 MCP 的时候，它会去调用这个 Skill 工具，然后明确表示要使用那一个 MCP Server，此时我们才把 MCP 的实际工具加载进去。这就是典型的渐进式发现逻辑。这一优化最高可以帮助我们节省 98% 的 Token 消耗。
另一个实践我们称之为任务复杂度分析。做法是按照用户 Query 的类别——也就是前面提到的那几个大类——再在各类别内部区分任务复杂度。区分复杂度的目的，在于判断哪些任务适合让什么样的模型来执行。当然，这一块目前也还在探索之中。我们越来越发现，当一个人以全栈的模式去完成一个复杂任务的时候，需要调度多个 Agent。主 Agent 调用 Sub-agent，Sub-agent 之间互相通信，而 Agent 背后仍然靠模型在驱动。我们希望能够有效识别 Query 和任务，让最合适的模型来承担相应的任务。我们就尝试依靠任务复杂度分析来做这个路由。假如任务复杂度极高，毫不犹豫上 Claude；如果任务相对简单，就用其他表现稍弱但成本更低的模型。这便是依靠复杂度分析来做模型路由的核心思路。
再分享一个与 GPT 模型相关的实践。近期在 Twitter 或类似媒体上，各位可能已经留意到 Codex 的声量在急剧攀升，其表现确实出色。Codex 搭配 GPT 模型的效果也很好，Comate 同样是支持 GPT 模型的。我们对 GPT 做过很多适配。可以看一张图，横轴代表一个 Query 里 Tool Call 的轮次，从零次到六十多次。我们用暴力的方式去做压测，观察整个工具的调用情况。其中有一个红色线的工具是 Bash，即命令行工具。起初当我们使用 GPT 模型的时候，我们提供了写代码的工具——Write、Read、Glob、Grep、Edit 编辑等工具，还有命令执行工具。但我们发现，越到后面的轮次，命令行工具的使用率就直线攀升——它不再使用我们定义好的工具去做代码编辑和文件写入了，转而使用命令行，用 Sed 命令，用 Cat 命令。
放在以前，这种情况会让我们相当苦恼，可能会在后面的轮次里明确告诉它：不行，你必须使用 Edit 工具，要压制模型的行为。但现在我们获得了全新的启发。通过这套监控机制，我们发现再去构建 Agent 工具，尤其是 Coding Agent 这类的工具时，更应该通过数据去观察模型真正喜欢什么。数据显示 GPT 的模型，特别是 5.3-Codex、5.4 这几个版本，特别喜欢用命令行。这也佐证了一件事——如果大家用过 Codex 的 CLI，就会发现它只有一个工具，就是命令行工具。这恰好说明了为什么 GPT 在构建 Agent 工具的时候，就是倾向于使用命令，而不是使用我们定义的结构化编辑工具。它天然就喜欢这种方式。所以当模型出现某些不遵循指令的行为时，我们可以先不要尝试去压制它、非要它遵循指令，而是去看它的异常。异常发生在这里，说明它可能喜欢这个东西，那我们就尝试再调一调，说不定能产生更好的效果。
以上是关于线上 Agent 线上数据的监控部分。接下来进入线下 Benchmark 的讨论，核心在于如何挖掘评测集以及发现异常值。出发点并不是看分数，而是看那些被分数掩盖的异常情况。
首先，评测集到底怎么构建？这一套体系目前我们自己在做探索，已经取得了一些相应的成效。尤其是从业务本身去挖掘评测集。当然 SWE-bench 那类评测仍然会跑。所谓“从业务本身挖掘”，具体的做法是通过 Comate 的提交记录来提取。Comate 每天都在做代码提交，这些提交都经过人的审核之后才合入仓库。我们把所有由人提交的记录全部拉出来，搞清楚是谁写的，拉出来之后做成一个 Feature，然后作为评测集，让 Agent 分析这些 Git Log 来进行信息提取，最后再由人工校验这些评测集的有效性，确认没有问题就作为一个正式的评测集。
这里可能会引出一个问题：你们的代码写不写单元测试？现在所有的 Benchmark 都在跑单测。但我们的这种评测和单测无关，它不是依靠单测来评的。因为不看分数，我们关注异常值，关注的是什么？当我们从业务层面把这个评测集挖掘出来并跑完一轮之后，就让另外一个 Agent 来跑这套评测的结果，由它推导出两个关键的参数：Outcomes 和 Execution Score。Outcomes 是度量结果的参数，Execution Score 是度量执行效率的参数。两个参数都由 Agent 来判定。我们只需要定义好一个 Schema，Agent 自己拿着评测跑出来的执行轨迹和结果来分析。
可能有人会心存疑问：让 Agent 去跑完结果，又让 Agent 去判结果，这不是左脚踩右脚吗？是否存在亲和性？事实上我们越来越发现情况并非如此。当我们用一个拥有干净上下文的 Agent 去评判另一个 Agent 所产出的上下文时，反而能够产生很好的效果和化学反应。他并不会给出非客观的判断，不是那样的，他完全可以给出很多客观的评价。因此我们不需要担忧让 Agent 验证另一个 Agent 会存在问题。这同时也衍生出一个推论：当我们在做代码评审的时候，如果倒推半年或许还能存疑，但当下用 Agent 去做代码评审已经不是问题了，它可以帮我们查出大量问题来。
具体拆解这些参数时，执行效率权重里面按照六四分，这个比例是我们拍脑袋定出来的。Agent 自行评定完这些指标之后，我们人也去同步验证，发现六四分大致合理，结果指标的权重应该更高一些。那么如何用这两个关键参数的组合来拆出四象限呢？组合之后可以生成四个象限：低结果低效率、高结果低效率、低结果高效率以及高结果高效率。回到我们讲 Benchmark 时的那个核心观点——不看分数，看异常值。低结果低效率的象限我们一般就不看了，肯定有问题，去调就好了。高结果高效率也不看。我们真正关注的是高结果低效率，以及低结果高效率这两个象限。按照正常的推理逻辑，既然你的结果已经这么高了，执行效率怎么能这么低呢？这就是异常值，我们要深挖。反过来，你的结果都这么低了，执行效率怎么还能这么高？同样也是异常值。
拿那个执行效率高但结果差的 20% 举个例子。这是某个最新的开源模型的表现。它所表征的含义是，这个 Agent 完成了一个评测任务，结果并不理想，但它自认为完成了，只调了几轮或者十几轮工具就宣告结束，所以执行效率的分数很高。但它并没有真正把这件事做好。这说明该 Agent 倾向于不做过多的自我验证，这就是我们要找的异常值。
在工具层面还有一个重要的实践。我们从 Case 分析中发现了一些模式：有一些不同的 Tool 经常成对出现。当编辑文件失败的时候，Agent 通常会去读取文件；读取失败了则去 List 目录；再不行就去做 Codebase Search 全文检索。这一连串行为经常成对出现。此外，从 Agent 的思考内容层面也很有价值，当我们在构建 Agent 时，可以发现它做出的计划是什么，它有没有真正按计划执行。还有一些修复类和 Debug 类的问题，Agent 经常会通过 Bash 创建临时文件来做排查。
这些规律推导出了一个我们称之为 Tools 的执行网络的概念。当下的 Coding Agent 工具，如果没有接近二十个工具几乎是不可能运转的。这里我只列举了少数几个，实际上工具数量远多于此。我们在评测集里发现，既然这些工具成对出现，它本质上就是 Agent 自愈能力的一种典型表现。比如写代码失败了，是不是因为这个文件之前读取的原文本身就错了？那就读一下吧。这个推理非常合理。因此，既然我们发现 Agent 天然喜欢这种行为模式，那就应该把它强化到 Loop 里面去。对于 Edit 这个工具，我们在它的描述中补充：如果你根本还没有读过这个文件，却想去编辑它，那你应该先去调用 Read 这个工具。如果读了好几次仍然没有办法发现你想要的东西，那就尝试去用 Codebase Search 做全文检索吧，不要再一个接一个地读了，那样太浪费上下文空间了。
我们把这一整套体系称为 Tools 的执行网络。意思是每一个 Tool 之间都是正交的，它们能够相互指引，形成一个类似指针的关系网络。通过这种方式来告诉 Agent，你可以这样去做，而不是去强行规范说“你写文件的时候必须把 old string、new string 写清楚”。不是那种方式，而是通过这种指引关系，让 Agent 拥有更多自愈的能力。我们会用一个状态机来管理这些工程性的变化，这同样也是一种 Harness，是在给 Agent 构建 Harness 过程中的一个具体技巧。
我们讲了做 Agent 时监控线上数据，用来调试 Agent，构建 Feedback Loop；也讲了本地评测，帮助我们发掘异常值，进而调整 Agent。但最终，所有这些事情还是要靠人去做。因此最后一个部分，想和大家分享 Agent Engineers 这个主题——把人放进 Loop 里。这个方向我们也在持续实践中，其中仍然有一部分带有畅想性质，自己还没有完全探索清楚，更多是抛砖引玉。
我们认为，把人放进 Loop 里有两层含义。第一层含义是，Comate 团队或者说各位在构建 Agent 的工程师，作为 Builder，作为 Agent 的构建者，应该去推动全员转型。现在我们正在推团队的全员转型，要求所有人都必须上去写代码，一竿子插到底地写代码。如果不亲手写代码，你几乎无法真正感知到 Agent 的变化。第二层含义是，当我们再去写代码的时候，Agent 会给我们提各种各样的问题，而人在这个过程中实际上被当作工具反馈，人被看作 Agent 工具的一部分。诚然，现阶段 Agent 仍然无法替代人，其中最替代不了的部分恰恰就在这个地方：产品决策、视觉、业务逻辑确认，那些 Sense 或者说 Test，那些品味。如今这个行业特别在讲的恰恰就是品味。
再具体一点，Comate 是怎么落地这个理念的？第一步是打破角色边界。我们现在已经不区分前端和后端角色了。但 Comate 作为一个已经将近四年的业务，代码库仍然区分前端和后端，技术栈是分割的。然而在具体实现时，做法已经不同。作为一个个体去完成一件事，除非遇到极其复杂的任务，确实不得不由前端的人去处理前端部分、后端的人处理后端部分，否则我们是分开做的。但凡稍微有一定难度的，我们都尽可能让 Agent 去跨栈完成。
第二步我们称之为反转协作链条，即先开发后定义。现在已经不是产品经理看到一个用户反馈、想到一个点子，然后交给研发去实现的传统模式了。大量情况下是研发人员先上去做。我先做出来，丑不丑没关系。在 Agent 的时代，我们真的还在乎产品丑不丑吗？我们还在乎 GUI 吗？前面也提到了，我们倾向于 CLI。先把能力做出来，然后再反向去和产品经理交底，再给交互视觉等工程师交底。这时候产品经理就开始帮你调整，交互这块稍微改一改，视觉稿我稍微给你设计点东西调整一下。
这种新的反转协作链条，又催生了新的 Feature 和新的诉求。我们希望 PM 和 UE 的原需求要实现原子化。能不能让 PM 不用每次都去交底，避免浪费精力，你也去写代码？视觉也别停留在现在的模式上了。于是我们就有了原子化的需求这一议题。能不能把你们的视觉稿、各类组件、你们的 Sense 做成 Skill？能不能把产品的各类限定条件与 Skill 结合起来放入仓库中，作为仓库的一种资产？当然这一点我们还在持续推进之中，实际上相当困难——把人的 Sense 真正做成 Skill，是一件非常困难的事情。
另一个我们正在做的实践是 Agent 全流程的验证。当我把这些东西全部做完之后，总是要做验证，要做测试。我们越来越发现，当让 Agent 端到端实现一个 Feature 的时候，最难的并不是写代码，而是验证一个 Feature 的有效性。怎么去验证？不是说简单的 Click 就算验证了，它需要验证整套逻辑。过去我们都依靠人、依靠 QA 来做测试。Comate 本身是一个桌面应用，有同学可能会问，用 Computer Use 不行吗？用 Browser Use 不行吗？但现实并没有那么容易，因为有些产品逻辑极其复杂，单纯依靠它而不把整个交互逻辑写好，是很难达到要求的。我们现在正在做的是通过沙盒，尽可能把这些验证过程完全交给 Agent 一个可执行的环境。之前我们所理解的沙盒，可能只是一个远程执行代码的容器。而现在我们的理解已经完全不同了——它是一种可授权、可观测、可回放、可验证、可交付的，完全提供给 Agent 的电脑，就像我们日常开发所使用的电脑一样。这是 Agent 的电脑，在里面 Agent 随便操作，搞坏了也没有关系，起一个新的沙盒就完事了。
最终，未来整个交付的变化趋势是，Agent 交付的内容将不仅仅是代码，而是包含一系列验证产物。比如我去做验证的时候，Agent 在沙盒里做验证是会有截图的，它必须能够自证。我们不追求人多自证，但 Agent 必须自证。怎么自证？你至少要构建出包来，你要编译通过，你要在自我做验证的时候留有截图——你看这个位置我 Click 了，我模拟了视频，这一整套流程我全都验证过了。这就是可验证的质量证据，意味着整个 Agent 从“你相信我”变成了“请你检验我”。以前写完代码之后，开发者说你看我写的挺好的，我完成了，你相信我，没问题——结果一上去一堆烂代码，CI 直接报错。现在不是这样了，通过这种方式，Agent 说的是请你检验我，你看我这个截图准不准，不准你就告诉我哪里不准，我马上就去改。此外，还有一个可追溯的决策过程，Agent 的执行轨迹本身就是一种交付产物。Agent 执行完毕之后，除了结果性的东西，其思考过程也应该以类似的方式沉淀为相关文档。我们在讨论这几个点，包括可复用知识沉淀，又衍生出了另一种 Harness。
虽然今天分享的主要内容并不是 Harness，但是不可避免要涉及它。在 Harness Engineering 之前还有一个概念叫 Context Engineering，即上下文工程。我个人认为，上下文工程更多是给做 Agent 的 Builder 用的——也就是像我这样的人，在 Comate 做 Agent 工具的人。在座相信也有不少做相关 Agent 工具的老师。Context 是模型所能够看到的东西，是给我们来考虑的。我们要怎么帮助开发者、帮助用户维护好 Context，保持它不腐化。而 Harness 是更高一层的工程概念。Harness 分为两类，一类就是前面给大家讲述的 Tools 执行网络之类的东西。Harness 中有一部分是给构建 Agent 的人使用的，另一部分是给用户使用的，给开发者在使用 Agent 写代码的情境下使用的。我所提到的第四点，可复用知识沉淀，也是一种 Harness。每一次让 Agent 写完代码之后，如果它在执行过程中某个地方写错了，而且你也注意到了，你就可以告诉它这个位置，叫它记录下来。未来你写代码的时候，你要参考它，不要再犯类似的错误。然后 Agent 就会在本地沉淀一个 Markdown 文档。这就是一种 Harness，是你正在教 Agent 怎么做。因此 Harness 应该分成两层，一层是给 Agent 的构建者用的，另一层是给各位作为开发者、作为用户来使用的。
站在今天这个时间节点上，我相信在座的每一位同学没有不使用 Agent 的，不在工作中使用 Agent 帮我们提升开发效率，不在生活中使用 Agent 帮我们获取信息、清洗信息。那么到了当下，尤其是研发协作这个层面，协作方式已经完全变了。我们的语言本身是不是已经变了？我在工作中经常发现，很多人跟进问题时会说“你帮我让他解决一下这个问题，他去排查太费 Token 了”。这句话就已经被 Agent 给感染了，被污染了。另外，整个组织协作实际上已经被完全重构了，协作链条已经反转了。当然我也非常认同，在当下，无论模型能力有多强，包括现在 Anthropic 因为安全问题还不敢发布的那个模型，仍然很难替代人去做某些事情。但它仍然是一个非常强的效率放大器，让强者恒强。善于提出好问题的人，会被 Agent 成倍放大。
作为构建 Agent 的团队，我也建议大家可以去尝试构建类似的 Feedback Loop，然后让 Agent 能够获得本地的 Benchmark，去发现那些异常，而不是盯着让分数更高来强化 Agent 的效果。尽可能在构建应用的时候，不要因为模型的发布，让我们整个产品、整个 Agent 框架感冒了。
