过去几年，AI 领域发生了一场静默的革命。我们曾经痴迷于模型的"聪明程度"——在静态基准测试上比较模型 A 和模型 B 的分数差距。但随着顶级模型之间的差距越来越小，一个残酷的现实浮出水面：这种评估方式根本无法反映模型在真实任务中的表现。当任务持续数小时、涉及数百次工具调用时，模型的能力差距才会真正显现。
这就是控智工程（Harness Engineering）诞生的背景。
1. 控智工程的定义
1.1 什么是控智工程
控智工程是围绕 AI 模型的软硬件基础设施系统工程。它的目标是管理长期运行的任务、确保 agent 的可靠性、效率和可操控性。控智工程回答了这个问题：当你拥有了模型的能力之后，如何让这种能力真正发挥作用？
业界有一个公式：Agent = Model + Harness。模型本身并不是 agent，只有当它被控智工程包裹起来时，才能真正执行有用的工作。
用一个计算机系统的类比来解释。如果 Model 是 CPU，Context Window 是 RAM，那么 Agent Harness 就是操作系统——它管理启动序列、处理上下文、提供标准工具接口，而 Agent 本身则是运行在这个系统之上的应用程序。
就像没有操作系统的裸机 CPU 无法发挥真正的能力，没有控智工程的模型也无法可靠地完成复杂任务。
1.2 控智工程与相关概念
理解控智工程，需要将它与几个相关概念区分开来。
Prompt Engineering（提示工程） 关注单次交互的优化——如何写好一条 prompt 让模型理解意图。控智工程关注的是整个 agent 运行系统的设计，包括状态管理、工具组织、反馈机制建立、上下文膨胀处理。提示工程只是控智工程的一部分。
Context Engineering（上下文工程） 是控智工程的上位概念，涵盖了所有与管理和优化 AI 上下文相关的技术。控智工程是上下文工程的一个子集，专注于通过配置和系统设计来管理 agent 的上下文窗口。
Agent Framework（智能体框架） 提供构建块——如何定义工具、如何实现 ReAct 循环、如何连接外部系统。框架告诉你如何搭建积木，控智工程则是把这些积木组装成能跑的赛车，而且要确保赛车能在赛道上稳定发挥。
2. 控智工程的目的
2.1 解决基准测试的局限性
传统的 AI 基准测试几乎只在单轮模型输出上评估能力。当我们看到某个模型在基准测试上领先另一个模型 1% 时，这个数字真的能说明问题吗？
答案是：几乎不能。真正的能力差距只有在任务变得漫长和复杂时才会显现。一道困难的谜题，模型可能在一两次尝试后就解决了——但它能否在第 50 次或第 100 次工具调用后仍然正确遵循初始指令？标准基准测试无法捕捉这种"持久性"（Durability）。
控智工程提供了一种新的评估框架：与其在静态测试上比较模型分数，不如关注模型在实际工作流中的表现。控智工程将任务执行转化为可观测、可记录的过程。
2.2 弥合模型潜力与用户体验的鸿沟
用户的实际体验往往落后于模型的潜在能力。即使是最强大的模型，如果缺乏合适的工具、反馈机制和上下文管理，用户也可能得到令人失望的结果。
控智工程通过提供工具和最佳实践来解决这个问题。当开发者使用合适的控智工程来配合 agent 时，用户能够真正体验到模型的最佳表现。就像一辆法拉利需要合适的赛道和专业的车手才能发挥性能，强大的模型也需要合适的控智工程来展现其能力。
2.3 建立反馈循环实现持续改进
有一句话说得不错：改进系统的能力与验证输出的容易程度成正比。控智工程的核心价值之一，是将模糊的、多步骤的 agent 工作流转化为可记录、可评分的结构化数据。
当每一次工具调用、每一次决策、每一个错误都被记录下来，我们就能分析 agent 在何时何地偏离了轨道。这些数据可以反馈到训练流程中，持续提升模型能力。每一次失败都是下一次改进的机会。
这与传统软件开发不同。在传统开发中，bug 修复就是终点；在控智工程中，agent 的一次失败应该触发系统层面的改进，确保它永远不会再犯同样的错误。
2.4 应对"苦涩教训"（Bitter Lesson）
Rich Sutton 在《苦涩教训》中指出：利用算力的通用方法总是击败依赖人工知识的手工编码方案。这个教训在 agent 开发领域正在重演。
看看行业中的案例：Manus 在六个月内重构了五次控智工程，移除僵化的假设；LangChain 在一年内三次重新架构其"深度研究"agent；Vercel 删除了 80% 的 agent 工具，结果反而减少了步骤、节省了 tokens、加快了响应速度。
这些案例告诉我们：轻量级基础设施比复杂的手写逻辑更具适应性。每当新模型发布，都需要不同的 agent 结构。那些过度设计的控制流，往往会在下一次模型更新时成为负担。控智工程的设计原则应该是：构建可删除的架构，准备好在模型进化时进行替换。
3. 控智工程具体是什么
3.1 上下文工程（Context Engineering）
上下文是 AI 模型最宝贵的资源，也是最容易浪费的资源。上下文工程是控智工程的核心组成部分，关注如何高效地管理和利用上下文窗口。
文件系统是上下文工程的基础设施。它提供了持久化存储能力，让 agent 能够跨会话维护状态。对于需要完成多天工作流程的 agent 来说，能够读写文件系统意味着能够跟踪进度、存储中间结果、记住之前完成的工作。文件系统还为多 agent 协作提供了天然的共享空间。
上下文压缩解决上下文窗口有限的问题。当对话接近上下文窗口上限时，控智工程需要智能地摘要和卸载已有内容，保留关键信息，删除噪音。这不是简单的截断，而是需要理解什么信息是重要的、什么可以安全地转移到外部存储。
工具调用卸载是另一个优化点。当工具输出非常长时（比如执行一个复杂的测试套件），保留完整输出会迅速消耗上下文空间。更好的做法是只保留头部和尾部 tokens，将完整输出存储到文件系统，让 agent 在需要时再访问。
渐进式披露（Progressive Disclosure） 是避免"指令过载"的关键策略。不要在 agent 启动时就加载所有可能的知识和工具，而是按需加载。这种策略类似于好的 UI 设计：只显示用户当前需要的信息，避免信息过载导致决策疲劳。
3.2 架构约束（Architectural Constraints）
约束是提高 agent 可靠性的关键。
OpenAI 团队在实践中发现：agent 在具有严格边界和可预测结构的环境中表现最佳。他们构建了一个严格分层架构的应用，每个业务领域被划分为固定的层次集合，依赖方向和允许的边都被严格验证。这些约束通过自定义 linter 和结构测试来机械执行。
这种做法在传统的人工优先工作流中可能显得过于死板。但在 agent 时代，约束成为了乘数：一旦约束被编码，它就同时在所有地方生效，无需人工反复强调。
边界隔离同样重要。模块边界定义了清晰的接口和依赖关系，帮助 agent 理解代码的组织方式。数据形状规范则确保边界处的数据结构保持一致，减少 agent 在数据转换上浪费的精力。
Martin Fowler 说过：增加 AI 生成代码的信任和可靠性，需要约束解决方案空间而非扩大灵活性。这意味着选择技术栈和代码库结构时，可能需要优先考虑"对 agent 友好"而非"最灵活"。
3.3 反馈与验证机制（Feedback & Verification）
agent 成功解决问题的能力与自我验证能力强相关。
自验证循环是让 agent 学会检查自己工作的机制，包括运行测试套件、执行类型检查、完成构建验证。关键在于，这些验证机制需要上下文高效——成功的验证应该是静默的，只有失败时才向 agent 报告问题。
自定义 Linter 是 OpenAI 团队的一个聪明做法：linter 的错误信息不仅是问题报告，还包含修复指南。当 agent 违反架构约束时，它得到的不仅是"你做错了"，而是"你应该这样做才对"。这种设计让 linter 成为了 agent 的实时导师。
持续集成确保每次新提交不会破坏现有功能。对于人类工程师来说，这可能意味着等待几分钟；对于 agent 来说，这意味着更快的反馈循环和更高的代码质量保证。
后向压力（Back-Pressure） 来自分布式系统，它的含义是：系统的处理能力应该与下游的消化能力相匹配。在控智工程中，这意味着验证机制应该与 agent 的执行速度相协调。
3.4 长期记忆与知识管理
AI 模型没有持久的记忆——每次新的会话都是白板一张。控智工程需要解决这个问题，让 agent 能够跨会话学习和进步。
AGENTS.md（或 CLAUDE.md） 是给 AI agent 看的 README 文档。它放在代码库的根目录，被 agent 在每次会话开始时自动读取。内容包括构建步骤、测试命令、代码规范、架构约束和常见陷阱。
关键在于，AGENTS.md 不是一次性编写的静态文档。每次 agent 犯错或遇到困难时，都是更新这个文件的机会。正如 Mitchell Hashimoto 所说："当你发现 agent 犯错时，花时间工程化一个解决方案，确保 agent 永远不再犯同样的错误。"
进度文件采用结构化的方式追踪任务状态。Anthropic 团队发现，使用 JSON 格式比 Markdown 更好——agent 不太可能意外编辑或覆盖结构化数据。这种做法类似于工程团队中的交接文档：新加入的 agent 能够快速了解当前的工作状态。
版本化知识库将设计文档、架构图、执行计划都纳入版本控制。agent 不仅能看到当前的知识，还能理解知识的演进历史，理解为什么做出了某些决策。
定时"垃圾回收"agent 是 OpenAI 团队的另一个创新。背景运行的 agent 定期扫描过时文档、发现不一致之处、打开清理 PR。agent 生成的代码会以不同于人类代码的方式积累混乱，这种机制帮助对抗这种趋势。
3.5 工具与能力扩展
MCP 服务器（Model Context Protocol） 是为 agent 暴露内部工具的标准方式。Stripe 的案例最为典型：他们的 Minions 通过名为 Toolshed 的 MCP 集成连接了 400 多个内部工具。agent 需要与人类工程师相同的上下文和工具，而非事后添加的集成。
沙箱环境提供了安全的代码执行空间。与其让 agent 在本地机器上运行可能危险的命令，不如将它们隔离在可控的容器中。Stripe 的做法是 Pre-warmed Devboxes——与人类工程师相同的开发环境，但沙箱化且预热。
专用 agent 角色是并行化的自然延伸。Anthropic 的 C 编译器项目中，不同的 agent 负责代码去重、性能优化、设计批评、文档改进等工作。这种专业化分工让每个 agent 都能在其领域内深入，而非试图成为一个多面手。
4. 控智工程的价值所在
4.1 对开发效率的提升
控智工程带来的效率提升是惊人的。
OpenAI 的内部团队仅用 3 名工程师，在 5 个月内交付了一个超过 100 万行代码的产品。平均每人每天产出 3.5 个 PR——而且随着团队成长，吞吐量还在增加。
Stripe 的 Minions 系统每周产生超过 1000 个合并的 Pull Request。开发者只需在 Slack 发布任务，agent 就会完成代码编写、通过 CI 验证、打开待审查的 PR，全程无需人工干预。
独立开发者 Peter Steinberger 创造了更极端的记录：一个月内完成 6600+ 次提交，同时运行 5-10 个 agent。他说，他只关注架构和重大决策，代码本身"他不读"。
这些案例的共同点是：人机比例发生了根本性的变化。一个工程师配上合适的控智工程，可以像一个小团队一样工作。
4.2 对代码质量的保障
一个常见的担忧是：agent 生成的代码质量能比得上人类吗？
答案是：取决于控智工程的质量。架构约束一旦被编码，就同时在所有地方生效。测试套件和验证机制确保 agent 输出的代码符合预期标准。自定义 linter 在问题萌芽时就捕获它们，而非等到代码审查。
当然，人工审查仍然必要。但控智工程改变了审查的性质——从逐行检查转向更高层次的把关。reviewer 关注的是：代码是否满足架构？设计是否合理？六个月后会不会成为维护噩梦？
4.3 对认知负荷的重新分配
Paul Graham 区分了"Maker's Schedule"（制造者日程）和"Manager's Schedule"（管理者日程）。使用 AI 编程工具正在推动工程师从前者转向后者。
不是"我写代码"，而是"我定义问题、审核结果、管理 agent"。不是"我知道怎么实现"，而是"我知道什么是好的"。
这种转变意味着更多精力投入环境设计和流程优化。这不是降低了对工程师的要求，而是对能力的要求发生了质的变化：对系统设计的理解、对质量把关的眼光、对工具和流程的持续优化，变得比编码技巧更重要。
4.4 竞争优势的来源转变
在过去，竞争优势可能来自于精心设计的 prompt 模板。在控智工程时代，竞争优势转移到了别处。
轨迹数据（Trajectories）——agent 在工作流中产生的完整执行记录——成为了新的数据资产。每一次 agent 在工作流后期未能遵循指令、每一次它偏离轨道、每一次它解决了本不该出现的问题，都是有价值的数据。这些数据可以用于改进控智工程本身，也可以反馈到模型训练中。
这也解释了为什么科技公司愿意在 agent 项目上投入大量资金：不是为了当下的产出，而是为了积累轨迹数据和运营经验。当别人还在学习走路时，你已经在收集最有价值的训练数据了。
5. 控智工程应该如何实现
5.1 核心配置点
构建控智工程时，有几个关键的配置点需要关注。
AGENTS.md 是最基础的配置点。它是 agent 进入项目后首先读取的文档，决定了 agent 的初始上下文。好的 AGENTS.md 应该是精心编写的、持续更新的文档，而非一次性生成的说明书。文件应该简洁（60 行以内），内容应该通用，避免过多条件规则。
MCP 服务器为 agent 提供额外的工具能力。但要警惕"工具过载"——当太多工具被加载到上下文时，agent 的性能反而会下降。Anthropic 甚至发布了实验性的 MCP 工具搜索功能，让 agent 能够渐进式地访问工具。更好的做法是谨慎选择，只连接真正需要的工具。比如，我现在常用的只有两个工具：context7 和 playwright.
Skills 提供了一种渐进式披露的机制。当 agent 决定需要某项技能时，相关的 SKILL.md 文件被加载到上下文，其中可能包含更详细的指令、示例，甚至指向其他文件的指针。
Sub-Agents 用于将任务封装到隔离的上下文中。这不仅有助于管理上下文膨胀，还支持成本控制——可以使用更便宜的模型处理子任务，只在父 agent 中使用高端模型。
Hooks 提供了事件驱动的控制流自动化。类似于 Git hooks，控智工程中的 hooks 可以在特定事件发生时自动执行脚本，比如在 agent 停止时运行类型检查、在失败时发送通知、在成功时自动创建 PR。
5.2 实践原则
基于多个团队的经验，以下原则被反复验证是有效的。
从简单开始。不要一开始就构建复杂的控制流。提供原子化的工具，让模型自主决定如何规划。实现 guardrails、retry 机制和验证，但不预设过多流程。
构建可删除的架构。模块化设计，准备好在模型更新时替换逻辑。新模型的能力会淘汰你昨天写的手写管道。过度工程化今天的设计，明天就可能成为负担。
先规划后执行。Cloudflare 的 Boris Tane 有一个简洁的原则：永远不要让 agent 在你审核并批准书面计划之前写代码。这种分离是单一最重要的事情——它防止浪费精力、保持架构决策在人类控制之下、产生更好的结果。
增量迭代。不要试图设计"完美"的配置再开始。每次 agent 失败时，花时间分析根本原因，然后针对性地添加配置。好的控智工程是演进出来的，不是设计出来的。
5.3 并行化策略
当任务规模变大时，并行化成为提高效率的关键。
监督式并行（Attended Parallelization） 指的是同时管理多个 agent 会话，主动检查和重定向每个会话的进展。Peter Steinberger 同时运行 5-10 个 agent，他作为"架构守护者"在它们之间切换，确保每个 agent 的工作符合整体方向。这种模式给予更多控制，但认知负担也更高。
无人值守并行（Unattended Parallelization） 则完全不同：开发者发布任务后离开，agent 处理一切直到 PR 阶段，人类只在审查时重新介入。Stripe 的模式就是这种。无人值守需要更成熟的控智工程——因为没有人类实时监控，控智工程必须足够可靠才能信任 agent 自主完成工作。
锁机制 防止多 agent 重复同一任务。Anthropic 的做法是通过文件系统锁：agent 通过创建任务文件来"认领"任务，如果两个 agent 尝试认领同一任务，git 的同步机制会强制后者选择不同的任务。
对照验证（Test Oracle） 是另一种高效的测试策略。核心思想很简单：找一个"已知正确"的参考物来对比验证。比如在重构一段代码时，旧代码就是"标准答案"——用同样的输入分别跑旧代码和新代码，结果不一样就说明重构引入 bug 了。这比直接写测试用例更省事，因为旧代码已经在线上验证过了。
5.4 避免的陷阱
同样重要的是了解什么是不应该做的。
不要预设过度的控制流。构建你认为"完美"的工作流程，然后发现新模型需要完全不同的结构。保持简单，让模型有发挥空间。
不要安装大量"以防万一"的 skills 和 MCP 服务器。这会导致上下文膨胀和性能下降。只添加真正需要的，移除不再使用的。
不要运行完整测试套件。5 分钟的测试套件会淹没上下文，agent 会失去对任务的追踪，浪费时间在分析测试结果而非解决问题上。运行快速子集，保持反馈循环紧密。
不要微优化子 agent 的工具权限。这导致工具震荡，带来更差的结果。大多数控智工程没有成熟到支持细粒度权限控制的程度。
6. 具体案例
6.1 OpenAI 的百万行产品（5个月）
这是最接近"工业级"规模的案例。
OpenAI 的一个团队用 3 名工程师、5 个月时间，从零构建了一个超过 100 万行代码的内部产品。他们的关键实践包括：
严格分层架构配合自定义 linter 强制执行。架构规则不是文档中的建议，而是被自动检查的约束。违反架构的代码在提交前就被拦截。
背景 agent 定期扫描过时文档。当发现不一致时，agent 会自动打开清理 PR——文档由 agent 维护、为 agent 服务。
最关键的文化转变是：每次 agent 失败都转化为系统改进。当 agent 遇到困难，团队问的不是"为什么这个 agent 这么蠢"，而是"我们的环境缺少什么"。
6.2 Anthropic 的 Rust C 编译器（约2周）
Anthropic 的 Nicholas Carlini 进行了一个实验性项目：用 agent 团队从零编写一个能编译 Linux 内核的 C 编译器。
项目规模是 100,000 行 Rust 代码、近 2000 次 Claude Code 会话、约 2 万美元 API 成本。最终产物能够编译 Linux 6.9（x86、ARM、RISC-V）、QEMU、PostgreSQL、Redis 等主流项目。
他们的关键创新包括：
Ralph Loop——一个无限循环的控智工程模式。当 agent 完成一个任务后，循环自动重新注入原始提示，强制 agent 继续工作而非停止等待。文件系统使得每次迭代都从干净的上下文开始，但读取之前的状态。
16 个并行 agent + 锁机制。每个 agent 认领不同任务，通过文件系统锁防止冲突。git 合并冲突频繁，但 Claude 足够智能来处理它们。
GCC Oracle。当多个 agent 都被同一个编译 bug 卡住时，使用 GCC 作为参考编译器来缩小问题范围。这种方法让并行工作成为可能。
6.3 Stripe 的 Minions 系统
Stripe 代表了更成熟的工程实践。他们的 Minions 系统每周产生超过 1000 个合并的 PR。
Toolshed 是 Stripe 的 MCP 集成中枢，连接了 400+ 内部工具。agent 拥有与人类工程师相同的工具访问能力。
Pre-warmed Devboxes 提供预热的隔离开发环境。这些环境与人类工程师使用的完全相同，只是沙箱化且预配置好。
Slack 触发让开发者可以通过 Slack 消息启动 agent。任务发布后，开发者可以离开，agent 完成代码编写、通过 CI、打开 PR，全过程无人干预。
6.4 个人开发者：Peter Steinberger
Peter 是独立开发者的代表。他用单人 + 5-10 个并行 agent 的模式，单月完成 6600+ 提交。
他的角色定位是"资深木匠"：agent 是执行者，做锯和胶的工作；他是设计师，知道什么是好的，拒绝不符合标准的结果。他不读代码行，只关注架构和重大决策。
Peter 指出：热爱解决算法难题的工程师很难适应 agent 原生开发，而热爱交付产品的工程师则很快上手。这提示我们，控智工程时代需要的技能组合可能与传统编程有所不同。
7. 总结
7.1 核心洞察
经过对这些案例和实践的梳理，我有几点核心洞察想分享。
控智工程不是临时补丁，而是工程学科。Mitchell Hashimoto 的定义最为精准："当你发现 agent 犯错时，花时间工程化一个解决方案，确保 agent 永远不再犯同样的错误。"这不是修补，而是一种系统性的工程方法。
约束创造自由。在直觉上，我们可能认为给 agent 更多灵活性会让它表现更好。但实践表明，约束——架构规则、边界、验证——实际上提高了可靠性和输出质量。问题不是"如何让 agent 做任何事"，而是"如何让 agent 可靠地做正确的事"。
控智工程是数据集。竞争优势不再在于某个精妙的 prompt，而在于捕获的轨迹数据。OpenAI 愿意资助这些 agent 项目，部分原因正是为了积累这些数据——这些数据可以训练更好的模型，也可以改进未来的控智工程。
构建环境和管理工作，两个能力缺一不可。agent 时代工程师的工作分成两个部分：构建环境和管理工作。它们不是先后关系，而是同时进行、相互影响的。agent 的失败告诉你环境缺什么；更好的环境让你能更轻松地管理 agent。
7.2 未来趋势
展望未来，有几个趋势值得关注。
模型与控智工程协同进化。Claude Code、Codex 等产品是在模型和控智工程共同迭代的环境中开发的。模型被训练来利用特定的控智工程模式，而控智工程也根据模型的特性进行调整。
上下文持久性成为新瓶颈。随着任务变得更长，上下文膨胀和"上下文腐化"（context rot）成为主要挑战。控智工程将成为解决"模型漂移"——模型在长任务后期偏离指令——的主要工具。
向无人值守工作演进。随着控智工程成熟和模型能力提升，更多任务将从"监督式"转向"无人值守"。Stripe 的模式可能成为常态而非例外。
7.3 给从业者的建议
最后，给那些希望开始在工作中应用控智工程的工程师们几点建议。
立即行动。不要等待完美的配置。今天就开始审视你的"控智工程"：你的 pre-commit hooks 里有什么？你的项目有 AGENTS.md 吗？你有自定义 linter 吗？从这些小事开始，逐步改进。
迭代改进。不要试图一开始就设计"完美"的控智工程。基于实际失败添加配置。每次 agent 失败都是改进的机会。
保持平衡。在效率追求和质量把关之间找到适合你和团队的平衡点。agent 可以跑得很快，但人类的判断力仍然是质量保证的最后防线。
拥抱变化。控智工程领域仍在快速演进。今天的最佳实践可能明天就需要调整。保持学习的心态，愿意尝试新工具和新方法。
控智工程代表了 AI 辅助开发和面向意图编程的新范式。它不仅仅是关于如何使用模型，更是关于如何系统性地设计人与 AI 的协作。模型提供了智能，控智工程让这种智能变得有用。
这是一个正在形成的学科，还有很多未知等待探索。但有一点是确定的：构建控智工程的能力，将成为未来工程师的核心竞争力之一。
