当我们构建 AI Agent 时，我们究竟在解决什么问题？

写在前面

这会是一篇很长的 Blog。我会按一个随意一点的顺序，聊聊这个标题。文中会插入不少链接：有的是例子，有的是观点的延伸阅读。它们不负责替我下结论，只给读者多一些可以自行判断的材料。

这篇文章更面向技术出身的读者，不会过多地解释基础概念，有一些背景知识我拆分了一篇单独的文章简单聊了聊。它不会是一篇只抛观点的文章，里面有不少例子和论证。准备读下去之前，最好留一点时间。

这确实是一篇很难开始的文章。我有很多想写的内容，但不太好写，我写了很久才找到一个勉强能用的切口。它读起来不会那么逻辑清晰，但我已经尽力了。

我相信这篇内容对于在搞 AI Agent 的读者会很有收获，但无法在开头讲清楚收获会是什么。这是一篇个人经验的随笔，不是教程。

让我们从故事开始。

一场大跃进

本文着笔在 2026 年 7 月下旬到 8 月上旬的几天里。在过去的半年里，AI Agent 领域经历了一场大跃进。如果非要划一个具体的时间节点的话，那么可以是从 OpenClaw 的爆火开始，一直到现在。

这里的大跃进借用了一段历史，它们在历程上有些相似。AI Agent 在过去的半年里很难说产生了什么 0-1 的质变，但无论是网易内部，还是说各个互联网大厂在 ToC 与 ToB 产品上，无数的产品和技术 Demo 都像下饺子一样被推出。腾讯在几个月里推出了数不清的 AI Agent 产品并丢出了铺天盖地的广告；阿里的大量职能部门在重组，钉钉经历了一场内部变革，并最终导致无招再次离开；字节甚至在合并豆包和飞书，很难想象有一天这两个软件会走到一起。几乎每家互联网公司甚至非互联网公司都搞出了自己的龙虾，各种不同背景的用户都在养虾。60 年前大练钢铁，现在是大练 Agent。

为什么？我们迎来了新的奇点？

科技存在奇点，但 OpenClaw 是那个奇点吗？Claude Code 在 2025 年中开放给所有用户使用，Codex 晚到一步在 2025 年 10 月 GA，Cline 也远比 OpenClaw 来得更早。自主决策，帮助用户修改和测试代码的 Agent 对于程序员来说并不稀奇，世界没有因此改变。OpenClaw 没有突破什么技术瓶颈，人类没有进入奇点后的世界，有的只是硅基智能增强以后一个水到渠成的新产品。

既然没有奇点，那为什么我们迎来了这场大跃进？

因为它爆火了。

普通用户在过去几年的 AI 浪潮中其实被落下了；他们每天都在看到 AI 的核弹又在爆炸，但自己从没理解这一轮 AI 是什么，会带来什么；他们焦虑，但直到 OpenClaw 的出现，焦虑才有了一个出口，或者说解药。

爆火之后呢？

在前 OpenClaw 时代，几乎所有的 AI Agent Dev 都被 Researcher 垄断。市面上只有 Researcher 和 VC 稍微懂 AI Agent 的基本原理，并了解它们大概能做到什么。不少在一线工作的程序员也在尝试接触 AI Agent，这是很喜欢拥抱新技术的一个群体。对于那些非技术出身的用户以及早早离开技术一线的管理层，他们接触 AI 的渠道可能只有豆包和手底下人的汇报，而汇报是怎么做的想必只要汇报过就懂了。虽然技术日新月异，但公司里仍旧维持着岁月静好。

现在 OpenClaw 闯入了这些管理层的视野，他们很多第一次知道 AI 竟然已经能落地干这么多事情了。如果不懂很多技术细节，可能会觉得它现在已经可以解决一切问题了。一种美丽的幻觉出现了。自上而下的压力到来，海量的 AI 项目被立项去争夺新的用户入口，内部 AI 提效的 KPI/OKR 被发放，各种背景的员工都要开始去学习 AI Agent 以填充相关的人员缺口，整个互联网行业似乎都被点燃。

一场 AI 大跃进到来了。

半年后的现在，新的用户入口逐渐稳定，各个行业的大量内部提效工具在各种尝试后大多失败，开发者对 AI 能力边界的认识逐渐清晰。大跃进在无声无息中结束了。

AI Agent 用半年的时间走过了很多行业 5 年的路程。

p.s. 如果你想了解 OpenClaw 为什么爆火，参考《BettaFish、MiroFish、OpenClaw 与 Agent 的信任边界》。

间章·一

这篇文章送给每一个在大跃进时期搞 AI Agent 的人，无论你是个人兴趣，还是吃了 KPI 压力。

我会尝试去回答三个问题：

当你在构建一个 AI Agent 的时候，你究竟在做什么？
当你想用 AI Agent 去解决一个真实场景里的问题时，你得先解决 AI Agent 自己的什么问题？
一个 AI Agent 项目为什么成功，又为什么失败？

很多人答不上来，这和他们的天赋与能力无关。每个人在大跃进时期都会有来自外部和内部的压力，大量的精力用于更快实现而不是思考这些问题。这些问题在过去两年里也被三四种不同的答案覆盖过，而每一种答案在当时都是对的。

有一层原因不在个人身上。大跃进真正的教训不是钢没炼成，而是指标替代了目标。炉子点着了，产量报上去了，至于炼出来的东西能不能用，在那个时候没有人问。我看到过的那些提效项目复盘里，有接入率，有调用量，有覆盖率，很少有“这段工作现在由谁做，比以前快多少，做错了怎么被发现”。指标完成得很好，工具没有人用。当指标本身取代了真实的目标，也就不会有人问为什么。

现在我们有时间来思考了。

这几个问题，光盯着这半年是看不出来的。半年的热闹更像水面上的浪花，洋流的方向和变化需要从更长的时间尺度来思考。在回答前面的三问之前，让我们先回到 2024 年，看看 AI Agent 的来时路。

来时路

这一章原本写在这里，后来拆成单独一篇：《AI Agent 的来时路：我们曾经以为瓶颈在哪》。它按时间顺序把过去两年走了一遍，分成七层：Prompt、RAG、Workflow、Tools、Context、模型与新词、评测。每一层都是一次关于瓶颈在哪的猜测，也都长出过一批工具、一批名词和一批项目；其中一些沉淀成了今天的基础设施，另一些投入了大量资源，最后发现此路不通。

后面的内容会反复引用那一章里的东西。如果你精通 Agent，不看也不影响阅读，看看那篇文章的小标题就够了；如果你想知道这些判断是从哪里长出来的，建议先去把那条路走一遍再回来。

间章·二

在开始提出明确的观点之前，有第二个间章。

聊了这么多过去的工程实现，好像有点偏离正题了。前面的这么多工程做法，其实都是遇见了各种各样的落地的瓶颈，然后我们在尝试去解决问题，去提高最后的 Agent 能力。从结果来看，我们取得了很大的进步，沉淀了很多有用的方案。它们都是对这三个问题的回答，稍微思考一下前面的每项技术是如何回答这三个问题的，应该就能想明白。

Try to think, no matter what you are building.

当你在构建一个 AI Agent 的时候，你究竟在做什么？
当你想用 AI Agent 去解决一个真实场景里的问题时，你得先解决 AI Agent 自己的什么问题？
一个 AI Agent 项目为什么成功，又为什么失败？

前面介绍留下了一些伏笔。Prompt 真的已经结束了吗？市面上还是有不少关于构建更好的 Prompt 的插件与 Skill，它们是在解决什么问题？训练可以带来知识，用 RAG 也可以带来知识，在工程上我们应该如何权衡？Context Engineering 覆盖的范围其实远不止压缩，不同的场景里我们可能要做些什么？Evals 非常重要，那篇文章也聊了各种 Evals 的手法，但工程上不会那么干净，我们如何抉择评些什么，如何迭代？

下面的内容更多的是一些个人经验和总结，我踩了很多坑，也在踩坑之后想了很多。当然我也在学习其他人的实践去思考。让我们从一些个人经历以及学习的案例开始，去回答我自己提出的三个问题，去聊聊当我们在未来要去做一个 Agent 的时候，应该去做些什么。

一些思考与判断

碎碎念与过去事

后面不少观点都基于一些个人经历，这里简单聊一聊我过去踩了什么坑，又攒下什么经验，可能会有点流水账。

我从 2025 年底开始研究安全 Agent，差不多做到 2026 年 3 月初，后面也看了一些朋友在这个领域的尝试与结果。我的讨论都将基于这些经历，不讨论更遥远的过去与未来。

我做的安全 Agent 相当简单，目标是构建一个可以帮我们从代码库中找到漏洞的 Agent Sys。挖掘漏洞的核心目的是去构建一个高质量的挖洞数据集，去考虑 Training 模型，来提高模型在挖洞这方面的能力。2025 年的通用智能体正在变强，但在这个专用任务上依旧较弱，选择去做 Training 在当时是一个不算错误的选择。

当然如果我们从未来的视角来看，我们正在做一个非常容易被通用模型能力取代的研究。Startup 的团队应该去思考模型的下一次升级会消灭还是增加自己产品的价值，做研究有时候就是一场小小的 Startup，不过我们在自己当自己的 VC。

具体的工作并不多，一个包含漏洞资料搜集、源码静态分析、污点流建模与自校验、CodeQL 引擎验证的多智能体系统。真实开发起来也就两周，其余时间都在调各种小问题。主要工作集中在折腾状态应该怎么表达，并设计一套好用的工具来实现与外部的交互；做一些静态的分析、验证和自我反思；配置一套 CodeQL 作为最终的验证机，来给出一个 True or False 的答案。收集一堆数据，洗一洗，跑一跑，打打 tag，做做课程学习，最终涨了点。这就是一个标准的 Post-Training Pipeline。

很多经验来自于 l3yx，在差不多相同的时间他在研究 AI Agent 用于自动化攻防，并在 TCH 智能渗透挑战赛拿了不错的成绩。他最早用 LangGraph 开发了一个非常复杂的 Multi-Agent 系统，把人类渗透的各种尝试角度做成了独立 Agent 与工具，然后增加了大量的渗透 SOP 与工具说明。这是一个集合了大量专家经验的通用 Agent，但专家经验局限于提示词；这是一个拥有海量工具的 Agent，但工具描述与反馈都会带来爆炸一样的 token。于是他提出了一个类似 Dynamic Workflow 的 Agent Framework，把专家经验与流程显式化；又做了一个类似 Programmatic Tool Calling 的调用优化，在老 MCP 和纯 Skill Script 之间找到了一个平衡点。

故事到这里只走了一半。

在第二届 TCH，l3yx 拿出来 Cairn，一个和前一代状态机多智能体协同完全不同的方案。一个 Dispatcher + 共享 Blackboard 架构，最小被调度单位是一个 Codex Agent，用来提出和验证假设。调度系统围绕最终目标构造 DAG，整个系统就是在无限状态空间里做一次有向搜索。Blackboard 只包含 Fact、Intent 与 hint，分别让 Agent 记录已有发现、未来目标和人类提示，以此实现通信。

没有任何流程被固定，全部由 Agent 根据问题和简单初始提示动态生成；按照功能与提示词流程注入的多智能体被取消，所有任务都在运行时才产生；所有的前向知识 RAG 与 Skills 被移除，相信模型这么多年过去以后已经很懂了。

这是一个极简的架构，但有时候简单架构比复杂架构更难设计。一个可以产生涌现的架构，和与它相配的模型，恰好在这个时刻碰上了。

前向知识注入，还是后向反馈？模型应当拿到什么信息

在 RAG 那一节，我提到了一个观点：RAG 从设计上就是单向的。我们花了两年时间，把“怎么把知识送进去”做得极其精细，却几乎没有人做“怎么把结果拿回来”。这是一种不对称。在 Function Calling 那一节我们聊到了 SWE-agent 以及 ACI，一个精心设计的工具与反馈信号在和 Loop 结合以后爆发了惊人的威力。2026 年模型能力的进步与自主 Agent 在 C 端的爆发则是这些故事的结果。

回顾一下两个安全 Agent 的例子。我做的代码漏洞挖掘 Agent，从外部资料的检索以及一些硬编码的流程和提示里获得前向的知识注入，从独立的静态自我检查和 CodeQL 引擎的验证中获得后向的反馈；l3yx 的第一代系统基于 LangGraph，依靠硬编码获得流程与知识，靠渗透代码的运行结果得到反馈；Cairn 抛弃知识与流程，靠模型内部的知识和渗透结果去完成任务。

在 AI 巨头们完成漏洞挖掘相关场景的预训练之后，我做的那套 Training 就失去了价值。一个通用模型依靠通用智能体，现在能取得远比我做的 Harness 更好的结果。模型的内部知识在越来越多的场景里完全足够，那么是花钱训练去扩内部知识，还是靠外部注入补齐，就变得值得权衡了。（p.s. 所以说训小模型之前要三思）

半年的时间里，模型的进步消灭了之前 Harness 与知识注入存在的空间。极简的结构配合可以泛化的模型，带来了远超各类知识注入与流程约束的最终性能。

写到这里我的观点应该已经很明确了。基础模型的进步不会停止，而模型的进步一定会消灭一些流程约束与知识注入存在的空间。模型懂得越来越多，值得被注入的世界知识只会越来越少，当你在想方设法规划流程、注入规则的时候，不妨去看看有没有给系统一个足够好的反馈信号。这可能才是现在的模型更需要的信息。

作为反馈信号质量的核心，ACI 的重要性我们在前面提到过一次。如果说做反馈是 0 前面的那个 1，那研究每一个工具的 ACI、以及这些工具应该如何被调用，就是后面的那些 0。**Tools 从来不是一份工具列表，而是 AI Agent 能看到、也能影响的整个世界。**把每一个 MCP Tool 做好是基础，但绝对不够。大量工具逐个调用带来的上下文开销同样需要处理，作为 MCP 的补丁，我们有 Programmatic Tool Calling；如果愿意去相信模型的能力，那不妨留下模型自己写脚本的空间（Skill Scripts）。l3yx 在两代系统里分别用了它们，都取得了不错的成绩。去精心打磨每一个 Tool 的描述，去调整一群 Tools 的覆盖空间，去规划系统能给出的反馈信号并将它们送回 Agent，然后思考怎么去调用 Tools。Function Calling 曾经是对的，Scripts 现在是对的，但未来还没到来。

反馈闭环是一个很有趣的 topic，《从反馈回路看 Agent 如何把生成变成搜索》里聊了 LLM 生成候选之后，系统怎么去搜索、验证、剪枝和选择，可以参考一下。

多智能体是否天然成立？人类分工如何变成 Agent 分工

在 Workflow 那一节我们聊了工作流框架的成功与多智能体框架的失败，在 Harness 那一节我们聊了 Single Agent 方案的大获全胜，也聊了 Subagent 把多智能体瘦身之后重新变得有用。多智能体的收益来自隔离的上下文，而不是像人一样的角色扮演。那我们还应该去做多智能体吗？如果做，应该做什么样的？

这是架构层面的决策，在开始讨论之前，先简单复习一下我们有哪些经典架构。

纯粹的工作流系统：n8n、Coze；一种低代码的编排结构
纯粹的多智能体系统：MetaGPT、AutoGen；通信系统是核心
用工作流约束的多提示词智能体：LangGraph；没有自由交流的多智能体，但有工作分离的 Prompt 与 Node 流转，一种中间态
有适当结构约束的自主智能体：Cairn、Dynamic Workflow；流程变得自由，约束变得宽松，但轻微的约束带来了更好的通信，起码不是多角色了
完全自主的智能体与 Subagent：Claude Code、Codex、PI；主 Agent 与 Subagent 委派

大致理解其中的思想差异即可，Agent 架构很难泾渭分明。理解它们之间区别的核心，可能在于开发的过程中，人往系统里注入了什么样的信息，又把什么留给了 AI 自己决策。

人类需要分工协作，原因在于人作为碳基智能的一些天然局限。人的认知带宽受限，不可能全知全能且精通各领域细节；人的精力也受限，无法长时间高效工作。因此我们用多人协作的形式完成复杂任务，这换来了大家能力的和，也带来了信息与认知交换的开销。

但现在的硅基智能不存在同样的能力边界与精力上限。把一个和人类不一样的智能，放进一个因为人的局限性才长出来的组织结构里，等于把人类的沟通损耗一起搬了过来。MetaGPT 与 AutoGen 的失败可能就在于此，而 CCC 的成功也不意味着这条路没错。

从 Startup 的角度看，这里还有一笔很现实的账。把一个任务拆成 Planner、Researcher、Coder、Reviewer，再套上一层通信协议，并不会凭空长出新的能力；很多时候，它只是把一个强模型本来可以完成的工作拆得更贵、更慢，也更难评估。模型的上下文、推理和工具能力再升级一点，这些人为角色很可能最先被吃掉。一个依靠“多 Agent 协作”讲故事的产品，应该先问自己：把这些角色拿掉，换成一个更强的 Single Agent，加上足够的 Token、工具和反馈以后，产品还剩下什么不可替代的东西？

不过，纯粹的多智能体并不是因此没有价值。关键不在于 Agent 会不会模仿人类部门，而在于身份、局部信息和独立状态是不是任务对象的一部分。社会模拟、市场行为、群体协作、舆情传播这类问题，研究的正是多个主体在非完全信息下怎样互相影响：不同主体看到的世界不同，有各自的目标、记忆和行动后果。此时把所有角色塞进一个 Agent 里再轮流扮演，通常只能生成一段像多方对话的文本，很难真的维持彼此独立、持续演化的状态。多智能体的核心价值或许不在普通办公协作，而在于为这种非完全信息世界建模。

其实本节的标题已经把答案说完了，这里再随便聊几句选型上的建议。

先抛开一切假设，从第一性原理去想你在做的问题的本质：你想用什么输入，给出什么输出，有什么原则要遵循。问一下自己为什么要用这个架构，这个架构本身想解决什么问题，并且永远不要回答“xxx 就是这么做的”。同时永不要让人类协作的架构去绑架 AI，架构永远基于问题本身和那些现在与未来的硅基智能的约束。

对于绝大多数内部流程工具和 C 端产品，一个打通了各个部门、各个模块，能获得输入与验证的 Workflow 系统，是高效且实用的。一点点 LLM 完全足够，也不必因为它不够高级而不满。很多任务本身就是流水线，把流水线做好才最重要。当然 Workflow 系统不意味着你应该直接选择 LangGraph，人类协作有流程是因为人的职能划分，但 AI 什么都懂，不一定需要这个职能划分，按工作本身而不是职能去切分，游戏开发中的管线是一个不错的例子。

还值得一提的选型其实只剩自主 Agent，前面我们把它分成了两类。当目标明确、但流程模糊的时候，就应该选它。两类多智能体的目标其实是一致的：做上下文的隔离与并行的加速探索。对于前面这种以完成任务为目标的执行型场景，不同的智能体本身是一样的，只是被派去做了不同的任务，Agent 的拓扑结构上只有任务，没有角色。

Cairn 是一个现成的例子。它上一代把人类渗透的各个角度做成了独立 Agent，每个 Agent 有自己的提示词、自己的工具、自己的位置；到了这一代，这些角色全都消失了，最小被调度单位退回成一个没有身份的 Codex Agent，Dispatcher 只管派任务，谁去做都一样。分工没了，并行还在，而且比上一代更快。并行是收益，分工不是，我们过去两年常常把这两件事当成一件事。

自主智能体之间的区别，其实只是通信结构的不同与约束程度的不同，挪一挪 Tradeoff 的位置，还能做出来更多东西。

本节已经比较完整地回答了多智能体与 Agent 技术选型的问题。对执行型任务来说，如何设计信息的隔离与交换，比定义 100 个 Coder 更有用；只有当身份、局部信息和独立状态本身就是要研究的对象时，角色才不再是包装，而是模型。Workflow 也永远会和自主智能体并存，这世界上的任务多种多样，AI 的能力边界也在变化，架构选择自然也是灵活的。架构本身就已经包含了对应的 Context 管理方法：工作流用约束把 Context 写进代码，多智能体把多个 Context 分开，再搭配常规的压缩与召回，这就是 Context Engineering 的全部。

我在《企业 AI 为什么总卡在试点？》里更多地从企业 Application 的角度聊了这个问题，也聊了那些不成功的 Agent 项目都来自哪里，有兴趣可以参考一下。

系统能力取决于人类表达能力？外部注入的不止知识

我们前面刚聊过应该侧重于反馈，而不是研究知识的注入，现在就来小小地打脸一下。Harness 要帮我们注入非常多东西：基础的 Prompt、系统状态、任务目标与约束、MCP 和 Skills 工具。很多注入是必要的，那它和我们之前聊到的那种注入，区别又在哪里？

Coding Agent 有两个功能值得拿出来聊聊。一个是曾经属于社区提示词技巧、现在变成 Agent 标配的 Plan Mode，另一个是社区热度极高的 Grill-me Skill。它们的核心提示词其实是一样的：找到我说的那些不足，然后不停提问，直到我们达成共识。这里注入的是知识吗？不是。这是在对齐那些没有写进代码、也没有写进提示词的规范与隐藏习惯。

No RAG 的思路是有局限的，很多任务光是描述任务目标和边界本身，就需要很多外部知识。而人类不是 AI，我们没有 /list 能够自动列出全部相关事项。当 AI Agent 变得如此万能，自主 Agent 系统的能力开始取决于人类的表达能力。去清楚且完整地表达一个意图，对于一个高度复杂的系统是有难度的。

p.s. 随着模型越来越好，Plan 其实会去吸收 Grill-me，但吸收需要找到那个平衡点。

我们以前聊 Prompt，聊的是措辞问题；后来发现好像不需要了；而现在 Prompt 变成目标定义的问题之后，又再度复出。模型的自主性一直在增强，而面向一个根本没有被定义清晰的目标去 Loop 没有什么意义，人自己都不知道目标是什么，Agent 猜对了也只是运气好。

我们来看看安全 Agent 是怎么处理这件事的。l3yx 第一代系统的目标与约束表达全靠人写的提示词，他确实是专家，但人的表达能力终究有局限，他不可能一次性把提示词写得面面俱到。Cairn 则只关注渗透这个最终目标，人能塞进去的只有一些简单的 hint，所有的 intent 由 AI 系统自己产生和迭代修改。这正是 Cairn 在这方面的价值：渗透的最终目标可以被轻松定义，hint 是随意的、不会带来错误的约束，intent 由系统迭代生成，也就不会被人的表达能力局限。

Cairn 起码在一类任务上，把所有信息的交换都做好了，所以它成功了。但完全没有考虑过这件事的 Agent，多的是。

你的 Harness 在补充能力缺口，明确任务本身，还是在补充信任缺失？如果模型真的不懂，那当然有必要。但如果只是因为它不按照你设想的方式做事，不妨尝试信任它一次。工程要释放模型能力，而不是压低模型上限。

对于一个 Coding Agent，值得被注入的知识包括技术栈、基础设施、规范、经验、架构、代码仓库本身的描述与索引、业务习惯、个人风格。当然做的时候也不能盲目，怎么分层注入进去、怎么确保它真的有用，比堆出一大堆东西更重要。

在 Workflow 与 Agent 上，问题描述的角度并不一样。调整系统结构，修改内部提示词，还是做提示词的增强，都属于这项工作的范畴，很难给出几条一定要做的建议，结合你自己的架构去思考这个问题，一般会有点作用。

哪怕 AI 变得再强，人永远无法从系统中被移除。在复杂的系统中，人需要去帮助 AI 过滤信息，找到那些对的，符合项目规范，符合个人品味的信息。纯粹的自由只会像 GPT 造的浏览器与 Claude 造的 C 编译器一样，在堆砌屎山的道路上狂奔。

Evals 到底要评什么？你凭什么说这一版更好

来时路的最后一层，我只说了别跳过 Evals，把怎么做留给了那篇 Anthropic 的博客。间章·二也留了一个问题：各种 Evals 的手法那篇文章讲得很全，但工程上不会那么干净，我们如何抉择评些什么，如何迭代？这一节来还这笔账。

当我们在构建一个 Agent 的时候，我们所做的一定是一个系统工程，同时需要系统的思维。对系统的评估一定是必不可少的一环，可以去看看你身边的每一个复杂系统，Evaluation 与 Trace 一定或多或少地存在。当然你可以先不做，因为有时候 Demo First，但要留下接口，并记住你前面其实没做它。

Evals 是 AI Agent 时代甚至更早的连接主义时代驱动下一阶段开发的核心动力，ImageNet 的存在让 CV 的每一个算法进步有依据可循，各大 LLM Benchmark 不断被提出再被新模型刷满，Evals 为技术的发展提供了方向指引。只要 Evals 本身阶段性正确，我们就能低成本地继续向后迭代；Evals 也能去定位问题，归因错误，用 A/B test 对比复杂系统的不同版本，让我们更快去修复；Evals 也可以有回归测试，让我们不至于倒退迭代。这就是 Evals 的价值。

有了评估，我们应该去修改什么呢？并不是每个模块都值得去修改，只有受控的小步修改、A/B test 与迭代才能通向一个更好的未来。我们总要固定很多东西，而这个问题不存在标准答案。每一个 Agent Dev 和 Researcher 都应该有自己的 Belief，去大胆地做出判断，然后用现实修正。我可以随便聊一点小经验。

Workflow 往往比 Agent Loop 更容易 Tracing，后者有时候我们只能拿到一个 A/B test 的结果和堆成山的 log，前者可以逐个节点地分析去跟踪 Trace。如果我们只有最终结果评测，它们看起来没有区别，但如果我们尝试去定位问题和归因，Tracing 还是有价值的。在理解问题后思考 Workflow 是否会是一个好答案，或者做做 Demo 和一些测试。系统拓扑是什么样的往往是最需要大胆判断的东西，这需要你去理解业务本身。

前向的知识注入，后向的反馈设计，系统每一处的提示词怎么设计是我们优化的核心。反馈和提示词一般只靠 A/B test，那么前向的知识注入的评测就值得思考。知识系统里每一篇文章是否都有足够的质量，所有的文章能否覆盖我们所需的知识，检索系统能不能工作，又给出了什么结果和业务效果。知识系统本身需要一直迭代优化而不是一次性开发，谁来优化又是谁来负责。检索失败有时候只是检索不到，这很容易定位，那谁来判断检索本身是否正确？这是比较值得考虑的问题，而不同场景各有各的问题。

这几年 Agent Benchmark 正在环境化，它从一份题目变成了一个可以跑起来的环境，而这个环境同时是执行的地方和判分的地方。SWE-bench 跑测试，tau-bench 看数据库终态，判分不是外挂上去的，是环境自带的属性。这和前面聊 ACI 时说的是同一件事：一个设计良好的环境，反馈信号更干净，评测也更容易做，两件事花的其实是同一份工程投入。能不能评，在你设计环境的时候就已经决定了。

至于工程上怎么抉择，我的经验大概是这样：

评什么：只评那些你会据此做决定的东西。要不要换模型、这次改 Prompt 是变好还是变坏、工具描述改一个词有没有用。
评多少：小而稳远好过大而全。20 条每天都跑得动的用例，比 500 条半年没人碰过的有用得多。
多久评一次：在会影响判断的改动之后。模型换代必评，因为你上一版的很多结论可能已经作废了。
什么时候可以不评：探索期和原型期可以不评，但要知道自己在欠账，而且这笔账迟早要还。
指标是目标的代理而不是目标本身：指标本身也需要评测，Reward Hacking 越来越是一个常见问题，不要让追求指标变成了目标本身。

最后提两个指标的事情。代码场景里常见的是 pass@k，跑 k 次至少成一次；而 tau-bench 提出的 pass^k 问的是跑 k 次能不能每次都成。前者说的是能力，后者说的是可靠性。这个区别在做自主 Agent 的时候格外重要：你敢给出多少自主性，取决于你对可靠性知道多少。一个 pass@5 很漂亮、pass^5 惨不忍睹的系统，不适合放手让它自己跑。能力决定它能不能做到，可靠性决定你敢不敢不看着它。

具体的评测方法可以回看前面提到的《Demystifying evals for AI agents》；pass^k 与 verifier 设计这条线，可以参考《Reward 与 Training 在真实 Agent 中如何闭环》。

写在最后

写到这里，我自己提的那三个问题其实都没有标准答案。如果一定要收一句，那大概是：构建一个 AI Agent，是在决定把什么交给模型、把什么留在系统里，以及凭什么相信这个决定是对的。

前面这些判断都会过期。模型每升级一次就会消灭一批 Harness，也会让一些今天还成立的结论变得可笑。每个人都有自己的 Belief，每个人的 Belief 也不是一成不变的，或许 1 小时后我就会有新观点，读者也应该有自己的观点。

还有一件事值得承认。多轮迭代不可避免，这不是因为 Agent 笨，而是人第一次说出来的需求本来就是错的。做 Agent 是这样，写这篇文章也是这样。

零零碎碎写了半个月，这篇总算是到终点了，下一篇大概率会聊聊最近的一些经历，做一个小小的总结。

一个关于 DGG 猜想的小注解

在这篇 Blog 逐渐成型的时候，其实 AI 圈子还发生了一个值得一聊的事情。**一个数学科研工作者通过反复 Prompt GPT-5.6 Pro 的方式，找到了 DGG/Goemans 成本猜想的反例，因此把它证伪了。**总提示数目只有约 60 个单词，AI 辅助数学科研不再是人完成 95% 并让 AI 补充，变成了人提出初步目标和简单方向，剩下全部交给 AI 去探索。

我们在前面聊到了”基础模型的进步一定会消灭一些流程约束与知识注入存在的空间……不妨去看看有没有给系统一个足够好的反馈信号。” DGG 猜想寻找反例的过程就是类似的生成变搜索。代码会验证 LLM 提出的反例是否正确，而反馈的存在将一次性生成变成了启发式搜索。而 DGG 猜想的证明方式可以意味着我们一直在高估知识，低估反馈。

在去年，如果我们考虑去构建一个 AI 数学家可能会做一些不同人设的 Agent，分析，批评，优化，证明等等。然后设计一套合适的通讯系统。但现在基础模型变得更强了，”强模型 + 足够长的搜索预算 + 高质量反馈” 可能就已经足够，复杂 Agent 的价值本身存疑。

不同领域的反馈是不一样的，如果你需要一个战略咨询 Agent，那反馈信号非常难以给出，广告就现实了很多，再进一步的代码已经有了更加廉价和充足的反馈信号，数学则拥有最为干净的反馈。AI 最早出现新发现的领域，很可能不是那些人类认为最需要创造力的领域，或许是那些拥有极强、极便宜、极自动化 verifier 的领域。现在的代码，未来的芯片设计，形式化算法验证。

当在构建一个 AI Agent 的时候，我究竟在做什么？我们所做的 AI Agent 与 Harness 到底是给模型带来了不可被替代的能力，还是弥补暂时的能力缺口。