薄下去之后，谁来决定怎么打

harness 变薄，不等于外面什么都不剩了。它上面会冒出另一层东西，对谈里还没想好该叫它什么，开玩笑说也许将来会叫「马鞍」。

这个说法不只是对谈里的即兴发挥。Anthropic 的工程博客写 Managed Agents 时用的正是「元 harness」这个词，定义是：一套不对「将来会需要哪种具体 harness」预设立场的系统，只提供通用接口，让很多种不同的 harness 都能跑在上面。

底下这三种打法，都已经有人在用：

真正用起来时，这几种打法还会混着来，而且分阶段。前期先用 best of N（同一道题独立跑 N 遍，再挑最好的那份）铺开探路，看哪条路走得通；等对的框架定下来，再在这一套框架上反复打磨。探索阶段和收敛阶段用的不是同一套策略。

值得留意的是，「多跑几遍挑最好的」并不是万能解。近年不少研究发现，在复杂任务上，反复独立重抽的效果会明显输给「带着标准反复改」，也就是下面要讲的 outcomes 走的路子。

Agent 要有自己的身份

今天绝大多数 Agent 干活，用的是借来的权限：它顶着某个人的账号进系统，那个人能进哪它就能进哪，出了事查到的也是那个人。对谈里的判断是，这条路走不远，Agent 得有自己的身份。

为什么非改不可，有两个绕不开的理由。一个是时间对不上：Agent 会自己排任务、在你早就下班之后才动手，这时候「代表你行事」本来就说不通。另一个是人对不上：一个群里三个工程师加一个产品经理，Agent 该按谁的权限办事？没有哪个人选在所有情况下都对。

下面这个来回，是对谈里描述的运作方式：

上面这个来回为示意场景，据对谈描述整理。

这套模型也有代价，Anthropic 自己在博客里点破了：可能出现「你本人进不去的房间，但你可以让 Agent 替你进」，只要那个隔间给了 Agent 这项权限。他们的说法是这确实反直觉，但对多人共用、自主干活的 Agent 来说是必要的一步。换来的好处是撤销变简单了：注销这个身份，它在所有系统里的访问权同时结束。

Agent 之间怎么互相调用

还有一条相关的线：把一个 Agent 包装一下暴露出去，另一个 Agent 就知道该怎么使唤它。对谈里提到有人在 Claude Managed Agents 上面搭了一层很薄的 MCP server 做这件事。

MCP 是 Anthropic 2024 年 11 月开源的一套协议，官方自己的比喻是「AI 应用的 USB-C 接口」。但真正让「另一个 Agent 就知道怎么调用」成立的，是它的一个具体设计：

视频开场那句自嘲，说的正是这件事。

能看出我们是 API 极客，因为我们说 Agent 之间该通过 API 互相对话。对谈开场白

别从 120 条流程开刀

企业算 Agent 这笔账时，最常见的两种起手式：把手上庞大的老流程全部 Agent 化，可能有 120 个，照着清单一条条来；或者干脆认为这正是彻底重做整个产品面的时机。想法都不错，但全部走一遍非常难。

对谈里给的替代方案是一个更简化的心智模型，顺序不能反：

按这个顺序走，公司在意的指标能一个个点亮，最后自然也能走到那份一直想梳理的 120 条清单。大多数 ROI 测算应该首先盯速度和产出效率，把它当主要抓手，通常更靠前也更奏效；等这套东西在公司里慢慢铺开，再往财务指标、用户指标上转就更合理。

人人都能单干，反而更难协调

问到失败模式时，对谈给的答案不太好听：Agent 会带来一种超级独立感，而这种感觉有点虚。

你会觉得现在人人都是开发者，什么都能自己做。以前你会想「这几个方案哪个最好」，稍微斟酌一下；现在反正便宜，十个原型全上，哪个赢了选哪个。

工程团队变成什么样了

结构其实没大变：你还是需要一群懂自己在建什么系统、懂怎么运维、出问题时怎么值班的人。变的是团队内部的配比。

稀缺的东西从「谁来写」挪到了「谁说得清该建成什么样」。

从一件件工具，变成一层底座

对终局的设想是：不再是一个个打开 Agent 工具，这个擅长这个、那个擅长那个。取而代之的是一层公共底座，大家都在上面协作。

界面还是熟悉的那些，但你可以随时叫上一个 Agent，想起就起，想停就停，它在背后默默干活。它甚至可能主动找上你：这东西挂了，我查了细节，弄明白也修好了，代码改动在这，你要不要看一眼。你也可以回一句，以后这么小的事别烦我，直接上线就行。

再往前，团队 Agent 会对上具体几个人之间的协作偏好：你和我之间某个协作流程有一个对应的 Agent，三个人的团队有另一个，它理解的偏好又稍微不一样。与其说是一件件主动去拿的工具，不如说更像一个操作系统。

平台侧的抓手叫 outcome

收尾落在一个具体机制上：你不告诉 Claude 怎么做，而是告诉它做成什么样算数，附一份评分标准。它自己反复做、反复对着标准打分，直到达标才停。

这不是口号，官方文档里是有具体设计的。定义一个 outcome 时，系统会自动配一个打分员，拿你给的评分表去验收产物；这个打分员用的是另一个独立的上下文，避免被主 Agent 自己的实现思路带偏。不合格就打回去重做，默认最多返工 3 次，上限 20 次。

沿着这个方向再往前，设想中的用法是：你说「我要这个结果，这是预算，开干」，剩下的基本不用再操心。

对谈给出的判断是：那一格正在被删掉。理由不在于删掉更简洁。那一格已经在拖后腿了。Anthropic 工程博客里记过一件具体的事，Sonnet 4.5 有个毛病，任务做到一半、眼看快到上下文上限时会草草收尾，团队管这叫「上下文焦虑」，于是在外壳里加了一个专门做上下文重置的补丁。换到 Opus 4.5 之后，这毛病自己没了，补丁变成他们原话说的 dead weight，死重。

能拆得动，是因为模型学会了在一个循环里反复「看情况、决定下一步、动手、看结果」。但外壳变薄不等于外面什么都不剩，它上面正在冒出另一层东西，对谈里的人还没想好该叫它什么，开玩笑说也许将来会叫「马鞍」。

这一层不规定第一步做什么、第二步做什么。它决定的是：这道题，用哪套打法去解。Anthropic 工程博客里管它叫元 harness。下面这张图把旧做法和三种新打法并排铺开，同一道题：小互要给一款新出的 AI 耳机写一篇 2000 字评测，手上有 12 条用户吐槽。

还有一件配套的事：模型自己想步骤之后，权限也得跟着换人。今天绝大多数 Agent（能自己排步骤干活的 AI 程序）用的是借来的权限，顶着某个人的账号进系统，那人能进哪它就能进哪。对谈的判断是这条路走不远：它会在你下班之后才动手，「代表你行事」本来就说不通；一个群里三个工程师加一个产品经理，它又该按谁的权限办事。换的方向是：它先报一份要碰哪些系统的清单，你逐项批、可以驳回，干成之后它有自己的账号，每次动作记在自己名下，事后能一条条查。

企业最常见的两种起手式是：把手上一百多条老流程全部改成 Agent 版，照清单一条条来；或者认为这正是彻底重做整个产品的时机。对谈里给的替代方案是一个更笨的顺序，而且不能反着来。以一家 40 人的内容公司为例，三级各要多久：

这些说法均出自 Anthropic 自己发布的对谈视频与官方博客，两位出镜者都在讲自家平台的方向，涉及产品能力的部分为一家之言；其中 outcome 等能力目前仍需单独申请，「Agent 给自己建服务账号」是对谈的说法，官方文档描述的做法是由管理员预置账号。