作者

MOD

文章 Lilian Huang · 五月 27 11m read

第三代Agent：线束工程（Harness Engineering）"如何再次改变游戏

#文档 #InterSystems IRIS #Artificial Intelligence (AI) #Generative AI (GenAI)

在上一篇文章中，我谈到了（iris-copilot），这是一种在不久的将来，任何人类语言都可以成为任何机器、系统或产品的编程语言的愿景。它的代理运行程序实际上就是在使用这种所谓的第三代Agent。为了自己的方便，我也想保留/分享一份关于它是什么的详细记录。我在最近的谈话中多次提到过这个问题，所以也许值得一记。

为什么泄露的 512,000 行Claude Code揭示了一种全新的范式——以及为什么你的 LangGraph 工作流程已经是传统的了

我们正在见证人工智能代理的世代飞跃，这几乎是巧合。

在过去的四年里，人工智能行业已经经历了三代不同的代理技术--每一代都不仅仅代表着渐进式的改进，而是我们对人工智能系统在实际工作中的思考模式的根本性转变。第一代为我们提供了信息（information）。第二代给了我们协调（orchestration）。第三代技术--我称之为 "线束工程"（Harness Engineering）--给我们带来了质的不同：信任。

这种转变最明显的证据是什么？这是在一个 npm 软件包中意外发布的。

意外的蓝图：Claude Code的 512K 行泄漏

2026 年 3 月 31 日，Anthropic 发布了 @anthropic-ai/claude-code v2.1.88 的例行 npm 更新。一个丢失的 .npmignore 条目意味着该软件包包含了一个 59.8 MB 的源图 - cli.js.map，其中包含了Claude Code完整的、未经过混淆处理的 TypeScript 源代码。共 512,000 行，涉及约 1,900 个文件。

图 1：源代码泄露揭示的 Claude Code 线束的五层架构。

几小时内，数以万计的开发人员对代码进行了镜像、剖析、Python 和 Rust 重写和研究。一个名为 claw-code 的无尘室重写程序在大约两小时内就达到了 50,000 个 GitHub 星级，这很可能是 GitHub 历史上增长最快的代码库。

这次泄密事件的特别之处并不在于代码本身。而是代码揭示了世界上最先进的编码代理究竟是如何工作的。而答案却出乎大多数人的意料。

模型不是护城河。线束(harness)才是。

泄露的代码库显示了一个 46000 行的查询引擎、一个 29000 行的工具定义库、大约 40 个模块化插件工具、44 个隐藏功能标志、一个三级权限系统、一个四级上下文管理流水线、23 个 bash 安全检查、Zig 级加密客户端验证，以及一个名为 KAIROS 的未发布自主守护进程和夜间内存蒸馏。

这些都不是 LLM。所有这些都是线束(harness)。

迄今已有三代理解框架

要理解为什么harness engineering代表着真正的模式转变，我们需要了解整个进化过程。

图 2：三代人工智能代理--从语义检索到自主工程。

第一代：RAG 和检索（2022-2024 年）

范式：语义信息和查询。

第一代人工智能实际应用是围绕 "检索增强一代"（Retrieval-Augmented Generation）展开的。突破性的见解简单而有力：LLM 有知识截止日期，会对事实产生幻觉，因此要将它们建立在自己的数据基础上。矢量数据库、嵌入管道、分块策略和检索链成为该领域的词汇。

RAG 解决了一个真正的问题--通过私人的、特定领域的信息使 LLM 变得有用。但从根本上说，这是一种只读模式。你可以对文档提出问题。你可以在知识库中进行搜索。你可以生成基于真实数据的摘要。但你不能做的是行动。

RAG 系统中的代理充其量只是一个具有自然语言理解能力的非常复杂的搜索引擎。它可以检索、合成和响应。它不会创建、修改、执行、规划或从失败中恢复。没有反馈回路。不使用工具。没有自主性。

RAG 在过去和现在都很有价值。但把它与代理人工智能混为一谈，就好比把图书馆目录与工程师混为一谈。

第二代：代理框架（2024-2025 年）

范式：预先定义的代理、工具和工作流程。

当业界认识到 LLM 不仅能回答问题，还能采取行动时，就出现了第二代 LLM。框架如雨后春笋般涌现：LangGraph、CrewAI、AutoGen、谷歌代理开发工具包（ADK）、语义内核（Semantic Kernel）等数十个框架如雨后春笋般涌现。MCP（模型上下文协议）和A2A（代理对代理）等协议规范了代理与工具以及代理之间的连接方式。

这是一次真正的飞跃。突然间，你可以定义一个搜索网络的 "研究代理"、一个编写 Python 的 "代码代理 "和一个检查输出的 "审查代理"--所有这些都在一个有向无环图中连接在一起。多代理协调成为可能。工具调用成为一流的功能。

但有一个问题，而且是最基本的问题。

在每一个第二代框架中，你都必须预先定义一切。

定义代理角色。定义可用工具。定义工作流程图。定义状态模式。定义切换条件。定义通信协议。你编写的代码是："代理 A 调用工具 X，将结果传给代理 B，代理 B 调用工具 Y，由代理 B 决定是循环返回还是终止"。

图 3：第二代和第三代方法的根本区别。

这种方法在你设计的工作流中运行得非常出色。但现实并非 DAG。需求会发生变化。边缘情况出现。需要新的工具组合。而每一次偏离预定义图都意味着要编写更多的框架代码。

LangGraph 提供了状态机。CrewAI 提供基于角色的团队。AutoGen 为你提供对话模式。Google ADK 为你提供函数调用管道。MCP 提供了工具发现协议。A2A 提供了代理通信协议。所有这些都是有价值的工程贡献。

但它们都有一个共同的基本假设：作为开发者，你必须在代理运行前对其行为进行架构。

代理就像你为它绘制的工作流程图一样僵化。添加新数据源？注册一个新工具。需要不同的审核流程？重新设计 DAG。想让代理处理意外情况？不能--除非更改协调代码。

这就是"先定义代理，后工作 "的模式。这种模式已经被取代。

第三代：线束工程(Harness Engineering)（2026 年 →）。

范式：设计环境，释放模型。

在Birgitta Böckeler在 martinfowler.com 上发表的奠基性文章的推动下，"线束工程 "一词于 2026 年初进入主流用法，随后，OpenAI、Addy Osmani的观点以及Claude Code泄露事件的启示也迅速出现。

核心观点体现在一个看似简单的等式中：

代理=模型+线束（Agent = Model + Harness）

"如果你不是模型，你就是线束"。- Viv Trivedy

这不仅是一个命名规则，更重要的是它彻底颠覆了设计理念：

在第 2 代，你定义了代理做什么。在第 3 代中，你定义了代理运行的约束条件，剩下的就让模型来解决。

线束设计的代理不需要 DAG 告诉它下一步该调用哪个工具。它有一个统一的工具界面（正如Claude Code泄露的信息所揭示的：身份、执行、验证、权限、展示）和一个权限系统，该系统管理哪些操作是安全的。模型决定做什么。线束决定允许做什么。

线束设计的代理不需要为 "研究者"、"编码者 "和 "审查者 "预先定义角色。它只有一个通用的代理循环，当任务需要并行时，它可以生成具有上下文防火墙和隔离工作树的子代理。

经过线束工程设计的代理不需要为每种可能的情况预设工作流程。在生成前，它有引导其行为的指南，在生成后，它有捕捉错误的传感器-——这就形成了一个能自主改进的自我修正反馈回路。

线束工程框架

Böckeler的框架提供了理论基础。Claude Code泄露提供了存在证明。它们共同定义了一门新学科。

导向器和传感器（Guides and Sensors）

图 4：导向器与传感器框架--前馈控制防止错误，反馈控制捕捉错误。

该框架区分了两种互补的控制机制：

引导（前馈，Feedforward）在代理生成代码前对其进行引导。它们提高了第一次尝试就正确的概率。例子包括

CLAUDE.md / AGENTS.md 文件，包含项目特定的规则和约定
架构蓝图和模板支架
包含特定领域知识的系统提示
限制解决方案空间的类型定义

传感器（反馈，Feedback）观察代理生成后的输出，并在人工审核前进行自我修正。例如

分类器、格式化器和类型检查器（计算传感器--快速、确定性强）
测试套件和拟合函数（计算传感器--可靠但有限）
人工智能驱动的代码审查（推理传感器--速度较慢，但语义丰富）
架构漂移检测（推理传感器--捕捉过度工程）

指南和传感器都有两种类型：

计算型：以毫秒为单位运行的确定性工具。可靠，但仅限于结构分析。
推理型：基于人工智能的工具，提供语义判断。功能强大，但具有概率性。

这与 "在您的 CI 流水线中添加一个线程 "不同。我们的见解是，这些控制构成了一个系统--通过累积的约束条件，使代理逐步提高可信度的集成线束。

棘轮模式（Ratchet Pattern）

图 5：棘轮模式--通过迭代改进线束来积累信任。

也许线束工程中最重要的概念就是棘轮模式（Ratchet Pattern）：每一次失败都会成为新的规则。

代理犯错
您诊断出根本原因--导向装置或传感器缺失
在线束中添加一个约束条件（CLAUDE.md，一个新规则，一个新钩子，一个新测试）
永久消除此类错误
信任增加；重复下一类错误

随着时间的推移，线束会积累制度知识。每条规则都可追溯到具体事件。线束成为 "所有出错事件以及我们如何防止其再次发生 "的活文档。

这与调整提示或调整框架参数有着本质区别。这是传统意义上的工程设计--通过系统化的约束和验证来构建可靠的系统。

证明这一点的架构

Claude Code泄露事件揭示了成熟的第三代安全工具在生产中的样子。五个不同的层，每个层都有特定用途：

图 6：同心线束架构--核心是模型，周围是内部线束（由构建者配置）和外部线束（由用户配置）。

输入和权限门- canUseTool() 作为中央看门人。分为三层：自动批准的只读操作、需要确认的状态修改操作，以及评估边缘情况的自动分类器（在单独的模型实例上运行）。
知识和上下文管理--四级管道采用模块化系统提示，旨在提高缓存效率；技能库采用渐进式披露；自动压缩可动态管理上下文窗口；跨会话的持久内存。
查询引擎- 46,000 行的大脑实现了带 "继续点 "的流式代理循环 - 多个退出和重新进入点，使代理能够在输出预算耗尽、上下文溢出和工具故障时恢复，而不会丢失进度。
工具系统--约 40 种工具采用统一界面。从简单的文件读取到复杂的网络搜索，每种工具都共享相同的契约：身份、执行、验证、权限和展示。新工具插入后无需更改协调层。
输出与多代理--具有上下文防火墙的子代理生成、用于并行工作的隔离 git 工作树，以及使用游戏引擎优化的 React + Ink 终端渲染引擎。

关键观察点：这些都不是工作流 DAG。没有 "先搜索，后代码，再审查 "的预定顺序。模型决定每一步该做什么。线束决定什么是安全的，并提供反馈，使模型保持在正确的轨道上。

为什么重要？趋同性证据（Convergence Evidence）

最有力的证据表明，线束工程代表了一种真正的范式转变--而不仅仅是人类学的方法--是趋同模式（convergence pattern）。正如Addy Osmani所观察到的，尽管底层模型和开发团队各不相同，但顶级编码代理（Claude Code,、Cursor、Codex、Aider、Cline）都趋同于类似的线束模式。

它们都实现了

具有权限层的统一工具接口
具有压缩和恢复功能的上下文管理
文件系统和 git 作为持久状态
作为通用执行环境的 Bash/shell
跨会话学习的内存系统
执行生命周期的钩子
安全执行的沙盒

这种融合表明，业界正在发现承重脚手架原则——这是任何通用代理在现实世界中可靠运行的结构要求。

OpenAI 的生产经验证明了这一点。他们的 Codex 团队构建了一个拥有 100 多万行代码的应用程序，其中没有一行是人工编写的。在五个月的时间里，仅有三名工程师的团队就打开并合并了大约 1,500 个拉动请求，平均每位工程师每天要提交 3.5 个 PR。秘诀不在于更好的模型，而在于更好的线束。而是更好的线束。

对实践者的启示

如果你目前正在使用第二代框架进行构建，那么这项分析并不是呼吁你明天就放弃它们。LangGraph、CrewAI 和它们的同类产品对于任务结构事先已知的、定义明确的、可重复的工作流来说，仍然是极好的工具。

但是，如果你正在构建需要处理通用任务的系统，也就是那种无法提前预测每个工作流的系统，那么第三代架构提供了一种根本不同的方法：

停止定义代理（agent）。开始定义约束（constraint）。与其编写指定代理做什么的协调代码，不如编写指定代理不应该做什么的规则。剩下的就交给模型的通用智能来处理。
投资传感器（sensor），而非监督员（supervisor）。每次当你发现自己在手动审查代理的输出时，都要问：我能否构建一个计算或推理传感器来自动捕捉这些内容？
采用棘轮模式（ratchet pattern）。将代理故障和防止其再次发生的规则记录在案。线束应从实际经验中有机地发展，而不是从假设的情景中发展。
设计可驾驭性（harnessability）。类型化语言、清晰的模块边界、成熟的框架以及全面的测试套件，都能让您的代码库更适合代理控制。这就是 Böckeler 所说的 "环境承受能力"。
分层思考（layer），而非流程（flow）。权限门、上下文管理、工具系统和反馈回路，而不是带有条件边的有向图。