🧠🛠✋🏻

最好的算法，是在最少的时间内做最合理的事情。同样，一直以来，AI Coding 要解决的核心问题都是：

如何在最大化 AI 价值，最小化时间、精力和花费的前提下，做出质量最高的产品？

对此，业界做了很多探究，各种概念和框架层出不穷。Anthropic 是 AI Coding 领域的翘楚，目标用户就是开发者，从他们的视角可以看到 AI Coding 的全局。

来看全局。

理想态

AI Coding 的理想态是让 AI 自己用最快的速度、花最少的钱鼓捣出来好东西。

拆解成三个点：“AI 价值最大化”、“成本最小化”、“高质量”。其中最重要的是第三点。前两点锚定方法，第三点定义标准。标准决定方法。

1. 产品质量

① 可用

完整实现所有功能，并确保功能经过充分测试，放到流程中可用。

② 美观

在保证可用性基础上，让人潜意识里产生美感的产品，我们认为是高质量的。

如何定义美？每个人对美的标准都不一样，如果让 AI 凭空去评估美，结果一定是不稳定的。但如果问“这符合好的设计原则吗？”，它就可以给出相对合理的评估依据。

Anthropic 定义的设计原则：

1）设计品质：是否是连贯的整体，而不是组件堆叠。颜色、排版、布局、意象和所有细节结合起来，是否能营造独特的氛围？

2）原创性：设计是源于创意？还是基于模版布局、Library 的预设 or AI 生成的样式？

3）精巧度：排版层次、间距一致、色彩和谐、对比度。

4）可用性：用户能否理解界面功能，不用猜就能完成操作？

3、4都是能力层面的要求，AI 擅长。而品质和原创性方面，AI 表现糟糕。

所以模型训练时，就会对诸如“白色卡片上覆盖紫色渐层”这种 AI 垃圾模式予以惩罚，并加大设计和创新权重，逼模型采取更具审美的策略。

2. AI 价值

AI 比人类高明的地方在于，在限定条件下高效做出最优决策的能力。要最大化 AI 价值，就要充分发挥这项优势。

3. 成本控制

成本即做出高质量产品所花费的时间、人的精力和 AI 的算力。

保质保量

试想一下，我们在做新需求时是什么流程？产品针对特定场景下的用户动机提出需求，交给设计和技术落地。

无论是设计，还是技术，都会对需求进一步拆解：具体有哪些功能，哪些可以复用/更改已有逻辑？哪些要新加？

可以看到，面对复杂需求时，我们人类不会直接开始做，而是拆解成小点逐步推进。（😒那又凭什么要求 Agent 拿到需求文档就 100% 完美实现呢？）

一、目标

限制：和人类一样，AI 的上下文窗口有限，复杂项目的任务们没法在一个窗口中完成，需要多个 Sessions。

问题：但是分散在多个 Sessions 里的任务没有上下文记忆。

目标：弥合 Sessions 之间的 Gap。

二、解法

理论上，具备上下文管理和Coding 能力的 Agent 应该能持续有效地工作才对。但实际，即使是 Opus 4.5，在跨多个上下文窗口完成复杂任务时，也还是不能构建出满足质量标准的产品。

它们一般会掉入以下两种失败模式中，导致无法完成任务。

模式 1 – 贪多嚼不烂

Agent 倾向于一口吃成个胖子，总想着一次性完成整个产品的构建。导致模型执行过程中，因为上下文溢出而中断。下一轮会话面对的就会是一个实现了一半、且缺乏记录的烂摊子。然后 Agent 就会去推测前面怎么了，还会耗费大量时间去让产品 Work。

像瀑布一样，止不住地一错再错。

模式 2 – 提前结束工作

部分功能构建完成后，Agent 审视项目时，发现有实质性进展，就会误以为任务全都完成了，然后宣告工作结束啦！👍🏻

了解了这两种模式特征，拆分两块解决：

首先建初始环境，引导 Agent 采取循序渐进、逐个击破的工作模式；其次，引导 Agent 在 Session 结束时，将环境恢复整洁（即：代码已达到合并主分支的质量标准，无重大 bug、代码井井有条、文档完备，人类工程师可以直接接手）。

基于上述方案，Anthropic 创造了两个 Agents：

1. 初始化 Agent：负责在首次运行时完成环境配置。包含用于初始化设置的 `init.sh`脚本 + 用于记录日志的 `claude-progress.txt` 文件 + 用于展示本次会话新增文件的一次初始 Git Commit。

2. Coding Agent：优秀工程师通常会通过查阅进展记录和 Git 提交历史来把握当前工作状态。将这个洞察迁移到 Coding Agent，它需要让每个 Session 开始时都能获取当前进展，并在编程结束时为后续 Sessions 记录清晰的阶段成果。

三、实施

这两个 Agents 的具体协作可以分成 4 个模块：

1. Feature List

初始化 Agent 负责细化用户提示词，编写出一份详尽的需求文档，让 Coding Agent 明白完整产品的最终形态。

Coding Agent 负责更新每个 Feature 的 `passes` 字段状态，其他都不许动（这个任务用 JSON 格式。相较于 Markdown，模型处理 JSON 文件时不太会发生不当更改和覆盖操作）。

2. 渐进式开发

要求 Coding Agent：

① 每次只专注开发一个功能。

② 写完代码后，必须把环境恢复整洁。具体：要求它提交到 Git，并附详细提交信息；要求它将进度摘要写入进度文件。这样，模型就能够通过回滚，快速撤销错误改动。

3. 测试

AI 往往在没有经过充分测试的情况下，就将功能标记为已完成，它无法识别功能在整体流程里并不 Work。

通过提示词，可以要求它使用自动化工具，并像人类一样执行全流程测试，这样，它才会去认真验证功能完整性。

但仍存在问题：受限于视觉能力，以及浏览器自动化工具的局限性，Agent 无法识别所有类型的错误（比如浏览器原生 Alert，这类功能更容易出 Bug）。

4. 基础但有用的步骤

除了上述三个模块外，每个 Coding Agent 还需要完成一些步骤，以确保每次启动时能核实产品是否状态异常，并立即修复：

① Run `pwd` to see the directory you’re working in. You’ll only be able to edit files in this directory.

② Read the git logs and progress files to get up to speed on what was recently worked on.

③ Read the features list file and choose the highest-priority feature that’s not yet done to work on.

降本增效

想让 Agent 更高效，光有吭哧吭哧干活的 Coding Agent 还不够，还需要一套架构，负责指挥大家跑起来，什么时候该想？什么时候该做？前因后果是什么？

这个指挥官就是 Harness，是降本增效的关键。

一、目标

问题：在设计 Harnesses、构建更高效的 Agent 时，往往会发现 AI 在某些方面是有局限的，这时就会针对这些局限设计特定解法。但随着模型能力的不断提升，这些局限可能不复存在，对应的解法也就成为了累赘。

比如上下文焦虑，即上下文窗口快满时，Agent 会提早结束任务。为了应对上下文焦虑，Claude 在 Harness 中加了“上下文重置”机制，但 Opus 4.5 不存在上下文焦虑问题，这套机制也就沦为了累赘。

目标：设计一套适配现在和未来所有开发场景的通用系统。

二、解法

Anthropic 提供了一项名为“Manage Agents”的托管服务，通过接口集提供能力，代替人类运行需要持续工作的 Agents。本质是 meta-harness。

这套服务将 Agents 的核心组件抽象为：“Session”（记录所有交互过程日志）、“Harness”（负责调用 Claude 并将 Claude 的指令路由至对应工具或容器）、“Sandbox”（隔离执行环境，供 Claude 在其中运行代码和编辑文件）。

组件抽象化后，可以被独立替换或更新，不会干扰其他组件。

🤔题外话：跟产品追求“整体性”不同，技术解决方案惯用“拼积木”的思路，比如这边 Manage Agents 的抽象化组件；又比如通过抽象实际硬件、用于部署和运行程序的 Kubernetes。总之就是，能共用的就抽象出来，一层层抽象，越干净越好。

三、实施

1. 工具化

起初，Session, Harness, Sandbox 都被放在同一个运行环境里，好处是，可以直接通过系统调用完成一些操作；也不用设计服务间的边界。坏处是，容器故障，Session 会中断、卡死，且无法调试。

此外，Harness 设计之初有个前提：Claude 处理的任务及数据，必须与 Harness 框架本身处于同一个容器中，导致 Harness 难以适配至不同的基础设施环境，客户使用门槛高。

要解决这两个问题，就得在底层重新拼积木：将“大脑”（Claude 及配套的指挥官）与“双手”（执行具体操作的沙箱及工具）以及“Session”（事件日志）彻底解耦。三者演进为相互独立的接口。任何一个故障，都能独立替换或修复，互不影响。

指挥官 Harness 不再寄居在容器内，而是跟其他工具一样，可以调用容器。容器崩溃，它反馈给 Claude，如果 Claude 决定重试，就初始化一个新容器。指挥官自己也一样，一旦故障，系统只需重启一个新实例，调接口拿日志，继续执行任务。同时，指挥官会持续调接口向 Session 写数据，确保所有事件日志都被持久化记录。

2. 上下文数据及管理

长程任务往往会超出上下文窗口，过往标准解法是选择性保留或丢弃上下文（例如压缩功能允许 Claude 保存摘要；记忆工具允许 Claude 将上下文写入文件，实现跨会话学习），但这些不可逆决策可能导致任务失败，因为不知道后面的任务需要什么 Token。如果消息压缩后发生了转换，Harness 会将这些已压缩的消息从上下文窗口中移除；除非额外存储，否则无法恢复。

Anthropic 的解法是：让 Harness 负责管理上下文；Session 负责上下文数据持久化存储。这样“大脑”想搞清楚事件发生的前因后果，可以随时回去查。

此外，“大脑”提取的事件，也可以先让 Harness 转换（内容取决于 Harness 的具体实现，可以是用来“提升缓存命中率”的上下文结构化重排，也可以是各类复杂的上下文工程。）后再送到 Claude 的上下文窗口。

四、收益

1. 降本 – 资源与时间

当“大脑”在容器中时，意味着有几个“大脑”就需要几个容器。无论会话是否涉及 Sandbox，每次会话都要承担完整的容器启动开销，都必须执行代码仓库 clone、进程启动以及从服务器拉取待处理事件等一系列操作。因等待而产生的空窗期，用“首个 Token 响应时间”（TTFT）衡量（指标含义：Session 从接收任务指令到生成首个响应 Token 之间所耗费的时长）。TTFT 是用户感知最为强烈、最为直观的延迟指标。

将“大脑”与“双手”解耦后，容器只在必要时，才会由“大脑”通过“工具调用”的方式按需配置。无需使用容器的 Session，就无需等待容器启动。一旦拉取到待处理事件，推理任务可以直接启动。

🤔题外话：在节省资源、缩短时间方面，“按需配置”也是技术侧的惯用方法。拒绝所有多余的动作和一切无意义的等待。

所以，现在事情就变成了这样：要启动多个“大脑”，只需启动多个 Harnesses；而 Harness 只有在需要时，才会和“手”建立连接。

这样就节省了资源、减少了延迟。Claude 的 TTFT 中位数（p50）下降了约 60%，而 TTFT 的 95 分位（p95）降低了 90%+。

2. 增效 – 横向扩展

因为没有任何一只“手”与特定的“大脑”耦合，各个“大脑”之间就可以相互传递“手”的控制权，每个“大脑”都可以同时操作多双“手”，这就大大提升了效率。

小记

Claude 的博文写得都很踏实，基本逻辑都是针对某个问题或现象，提出一套解决方案，且可以看到解法和解法之间渐进发展的脉络。

OpenAI 4/15 也发布了博文，类似的底层架构。但文章只介绍了功能，“支持了xxx”、“现在可以xxx”，没有具体场景的来龙去脉，感觉像凭空冒出来的，就不看了。

参考：

[1] Anthropic Blog: Effective harnesses for long-running agents

[2] Anthropic Blog: Scaling Managed Agents: decoupling the brain from the hands

---

欢迎关注：