12个生产级Agent团队的设计密码：两个问题决定成败

为什么模型之外的一切更重要

所有团队都在用相同的几个模型，但生产环境中的表现却天差地别。Reddit上一位研究者阅读了12个正在生产环境中运行Agent的团队公开资料，包括Codex、Claude Code、Cursor、Devin、Stripe的Minions、Manus、Agentforce、Shopify Sidekick、Sierra、Intercom Fin、Harvey和Hebbia，试图回答一个问题：围绕模型的那层代码——也就是harness——到底在做什么？

据Fortune对Anthropic事故复盘的报道，Claude Code曾在3月和4月经历约一个月的明显能力下滑：一次改动让模型在会话中途丢弃自己的推理历史，另一次则将工具调用之间的回复限制在25个词以内。整个过程中API本身没有变化。同一个模型，不同的harness，结果截然不同。这足以说明，harness不是锦上添花，而是决定Agent能否稳定工作的关键层。

Harness 是围绕大语言模型构建的运行时框架，负责管理上下文注入、工具调用编排、状态维护、错误处理与验证等环节。它决定了模型在每一步看到什么信息、能执行哪些动作、输出如何被校验与修正。在Agent系统中，harness相当于模型的“操作系统”：模型提供推理能力，harness则决定这种能力被如何组织、约束和放大。Anthropic事故中，API未变而harness改动导致能力下滑，正说明harness对最终表现的支配性影响。业界逐渐形成一个共识：模型是通用商品，harness才是产品差异化的来源。

十二个团队的三个共识

尽管产品形态各异，这12个团队在harness设计上表现出高度一致的三个做法。

晚一点加载上下文

Codex维护一个约100行的AGENTS.md作为索引，指向更深的文档；Cursor将长输出写入文件，让Agent在需要时自己读取；Sierra采用渐进式披露。没有人再为巨大的静态提示词辩护。上下文不是一次性塞满，而是按需展开，这既节省token，也避免模型在无关信息中迷失。

把已知步骤写进代码

Stripe的blueprints将确定性节点与Agent节点混合编排；Salesforce直接在代码中写路径；即便是最“Agent优先”的Harvey，也把文档状态牢牢控制在模型之外。凡是能预先确定的流程，就不交给模型即兴发挥。

用生成器之外的东西做检查

Devin的reviewer在干净的上下文中运行；Harvey的起草Agent用diff工具核对自己的修改；Shopify将LLM裁判与人类判断的一致性从kappa 0.02校准到0.61（人类之间的一致性为0.69）。生成和验证分离，是防止错误累积的基本纪律。

Cohen's kappa 是衡量两个评估者之间一致性程度的统计量，计算时扣除了随机一致的概率。取值通常在-1到1之间，0表示与随机猜测无异，1表示完全一致。在LLM裁判场景中，kappa用于量化自动评估与人类判断的吻合度。Shopify将kappa从0.02校准到0.61，意味着裁判结果从几乎随机提升到与人类高度一致；人类之间的一致性为0.69，可作为参照上限。这一指标比简单的准确率更有说服力，因为它排除了评估者偶然猜对的情况，能真实反映自动裁判是否可靠到可以独立承担验证职责。

两个问题解释几乎所有分歧

在共识之外，12个团队的做法出现了明显分化。研究者发现，几乎所有的分歧都可以用两个问题来解释：错误被发现的成本有多低？错误被漏掉的代价有多大？

Stripe是最清晰的案例。其代码每年流转超过1万亿美元，漏掉错误的代价极高。但Minions却以完全权限运行，没有确认提示。原因在于每个Minion都在隔离的开发环境中工作，CI最多两轮，且每个PR都有人工审查。Stripe把“发现错误”变得极其廉价，所以才有底气跳过“询问”这一步。

Codex则相反，它可以暂停一轮对话等待人类批准。两种做法都没有错，只是对两个问题的回答不同。

同样的透镜也解释了其他分歧：Cognition保持单一写入者，而Manus并行运行子Agent，但两者都不允许并行Agent在没有协调者的情况下写入共享状态。那些直接操作记录系统（system of record）的Agent——Agentforce、Sidekick、Sierra、Fin、Harvey、Hebbia——处于错误难以实时发现、漏掉代价高昂的位置，因此它们把资源花在确定性闸门、离线评估、回滚和审计追踪上。

System of record（记录系统）指组织中作为权威数据来源的核心系统，如CRM、ERP、订单管理系统或电子病历。写入这类系统的操作具有持久性和高影响：一旦错误数据进入，可能触发下游流程、影响多方决策，且修正成本远高于在沙盒或草稿环境中纠错。因此，直接操作记录系统的Agent必须配备确定性闸门、审计追踪和回滚机制，而不能依赖模型即兴判断。这也解释了为何Agentforce、Sidekick、Sierra、Fin、Harvey、Hebbia等团队把资源集中在离线评估与人工复核上——它们的错误一旦漏掉，代价不可逆。

一个意料之外的空白：没人公布“成功任务成本”

最让研究者意外的发现是：12个团队中没有一个公布“每个成功任务的成本”。每周PR数量、单次运行准确率倒是有很多。Fin公布pass^k，Cursor公布keep rate，Shopify公布裁判一致性。但几乎没有人说明一个真正起作用的（即“成功了”的）任务花了多少钱。

这留下一个关键问题：如果你不知道成功任务的成本，你就无法判断Agent是否真的比人类更经济。研究者本人也在用这个指标衡量自己正在构建的AI研究Agent，包括每份被接受的草稿成本。

pass^k 是一种评估Agent可靠性的指标，衡量的是同一任务重复运行k次时全部成功的概率。与单次准确率不同，pass^k强调稳定性：一个单次成功率90%的Agent，在k=5时全部通过的概率可能只有约59%，暴露出偶发失败的风险。对于生产环境而言，可靠性比峰值能力更重要，因为用户会反复使用同一功能。Fin公布pass^k，正是为了说明其Agent在多次重复中保持一致表现的能力，而非仅展示最好情况下的结果。

需要留意的局限

研究者坦承，收集的83条声明中有66条来自公司自述，且他本人并未实际运行这些harness。此外，这篇分析的初稿来自他正在构建的一个AI研究Agent，他做了编辑，并公开衡量该Agent的成本。

对于正在运行Agent的团队，他留下两个问题：你是否追踪每个成功任务的成本，或者接近它的指标？你如何定义“成功”？如果你运行这12个之一而他的描述有误，你遗漏了什么？

完整对比、每条声明及其日期和来源链接可在其网站查看。