线束工程：人类掌舵AI代理执行的软件开发新范式

引言：一个Token亿万富翁的实践

OpenAI技术人员Ryan Lopopolo在AI Engineer大会上分享了一个激进的实践：过去九个月里，他禁止团队成员触碰编辑器，所有代码必须通过AI代理完成。他自称"Token亿万富翁"——每天消耗超过10亿输出Token，折合超过1000美元。

Token是大语言模型处理文本的基本单位，英文中大约每个单词对应1-1.5个Token，中文每个字约1.5-2个Token。每天消耗超过10亿输出Token意味着模型每天生成的文本量相当于数百万页文档。按照OpenAI当前API定价，这一消耗量折合的成本远超普通开发者的使用规模，反映出工业级AI辅助编程与个人使用之间存在数量级的差距。

这不是一个关于未来的畅想，而是一份来自前线的实战报告。Ryan提出了"线束工程"（Harness Engineering）的概念——一种全新的软件工程方法论，核心理念是：代码是免费的，人类的角色是构建系统、结构和约束，让AI代理完成全部实现工作。

线束工程的核心理念：代码已经免费

实现不再是稀缺资源

Ryan认为，当前阶段发生了三件关键的事情，彻底改变了软件工程的格局。其中最重要的是大模型在代码生产能力上已经与人类同构——能够完成软件工程师的全部工作。

所谓"与人类同构"，指的是大模型不再仅仅擅长代码补全或片段生成，而是能够理解需求、设计架构、编写完整模块、处理边界情况、编写测试——覆盖软件工程师日常工作的全链条。这一能力的飞跃源于Transformer架构在海量代码语料（GitHub上数十亿行开源代码）上的训练，以及RLHF（基于人类反馈的强化学习）和代码执行反馈等后训练技术的成熟。

这意味着什么？每位工程师现在拥有5个、50个甚至5000个工程师的产能，全年无休。代码免费生产、免费重构、免费删除。那些永远排在P3优先级的任务，现在可以立即启动，甚至并行启动四个方案，选最好的合入。

稀缺资源的转移

在这个新世界里，真正稀缺的资源变成了三样东西：

1. 人类时间 —— 需要投入到更高杠杆的活动中
2. 人类和模型的注意力 —— 需要精心管理
3. 模型的上下文窗口 —— 需要高效利用

工程师的角色从"写代码的人"转变为"Staff Engineer"——负责系统思维、系统设计和任务委派，管理一支由AI代理组成的团队。在硅谷科技公司的职级体系中，Staff Engineer是位于Senior Engineer之上的高级技术职级，其职责从个人代码产出转向技术方向制定、跨团队协调和系统级决策。Google、Meta等公司的Staff Engineer往往不再日常写代码，而是负责技术规范制定、架构评审和技术债务治理。Ryan将所有工程师的角色类比为Staff Engineer，本质上是说AI代理承担了"手"的工作，人类需要升级为"大脑"。

什么是好的线束工程实践

让AI代理做好工作的关键

Ryan指出，做好一个补丁可能需要500个关于非功能性需求的小决策。非功能性需求（Non-Functional Requirements, NFR）是软件工程中与功能逻辑无关但对系统质量至关重要的约束，包括性能指标、安全标准、可维护性、代码风格、错误处理策略、日志规范等。一个经验丰富的工程师在写代码时会隐式地做出数百个这类决策——比如选择同步还是异步、是否需要重试机制、日志级别如何设定。这些决策通常存在于工程师的"肌肉记忆"中，从未被显式文档化，而线束工程的核心挑战正是将这些隐性知识外化为代理可读的指令。

模型在训练中见过数万亿行代码，涵盖了所有可能的选择。工程师的工作是把这些非功能性需求写下来，让代理能够看到什么是"可接受的好工作"。

核心方法是：一切都是Prompt。Ryan列举了多种向代理注入指令的方式：

• agents.md文件
• Rules文件
• Skills（技能文件）
• Lint错误消息
• Review Agent在PR上注入的评论
• 嵌入代码中的Agent SDK

agents.md是一种约定俗成的仓库级配置文件，类似于README.md，但专门面向AI代理编写，包含项目架构说明、编码规范、禁止事项等。Rules文件和Skills文件则是Codex等AI编码工具支持的结构化指令格式。这些机制的本质是将传统的"团队编码规范文档"转化为机器可执行的Prompt，使AI代理在每次任务开始时自动加载项目上下文，而非依赖人类在对话中反复说明。

AI代理的实际工作流程

Ryan的团队以Codex为入口点，而非围绕它构建环境。他们给Codex提供技能（Skills），教它如何启动应用、启动本地可观测性栈、连接Chrome DevTools等。整个仓库和本地开发工具都优先为Codex设计。

团队将技能集中在5-10个核心技能上，不追求广度而追求深度。一个有趣的例子是：当底层从Chrome DevTools Protocol迁移到daemon架构时，Ryan三周后才发现这个变化——因为Codex凭借文档自己就搞定了。

代码库的结构化策略

为AI代理优化代码组织

随着项目规模增长，Ryan的团队采取了"10000人工程组织"级别的架构：PNPM工作区中750个包，按业务逻辑域或系统层级隔离。

PNPM是一种高性能的Node.js包管理器，其工作区（Workspace）功能允许在单一代码仓库（Monorepo）中管理数百个独立包，每个包有自己的依赖声明和构建配置。750个包的规模在人类团队中通常只出现在Google、Microsoft等拥有数千工程师的组织中。Ryan将三人团队的代码库拆分到这种粒度，核心目的不是为了人类的组织管理，而是为了AI代理的上下文管理——每个包足够小，可以完整放入模型的上下文窗口，代理无需理解整个代码库就能完成局部任务。

这样做的原因是：

• 代理可以将工作范围限定在目录子树中
• 文件系统中的代码本身就是给代理的Prompt
• 代码越统一，模型预测所需Token就越容易、越一致

具体实践包括：只有一种并发辅助方法、一种ORM、一种编程语言、一种CI脚本写法。Ryan建议在团队中做"独裁者"——确定唯一的做事方式，写下来，然后让代理迁移整个代码库。

源代码级别的测试约束

Ryan分享了一个巧妙的技巧：编写关于源代码本身的测试。例如，限制文件不超过350行——这是为了适应模型的上下文窗口，从工程角度优化上下文效率。大语言模型的上下文窗口（Context Window）是指模型单次推理能处理的最大Token数量，目前主流模型的上下文窗口从128K到200K Token不等。限制文件不超过350行（约5000-7000 Token）的策略，确保单个文件加上任务指令、相关依赖信息后仍能舒适地放入上下文窗口，避免因上下文截断导致模型丢失关键信息。这是一种"为读者（AI）而非作者（人类）优化代码结构"的范式转变。

同样，错误消息必须提供实际的修复步骤。不是简单地报告"这里有个unknown"，而是告诉模型："你不应该在这里有unknown，因为我们在边界处解析而非验证，你这里应该有一个从Zod派生的类型。"

这里提到的"解析而非验证"（Parse, Don't Validate）是函数式编程社区推广的一种类型安全设计模式，由Alexis King在2019年提出。其核心思想是：在系统边界处将非结构化数据（如API请求、用户输入）解析为强类型数据结构，之后在系统内部只传递已验证的类型，从而在编译期而非运行时消除非法状态。Zod是TypeScript生态中最流行的运行时类型验证库，能够从Schema定义中自动派生TypeScript类型，实现运行时验证与编译期类型检查的统一。将这一设计哲学写入错误消息，等于在代理犯错的瞬间向它注入了架构级的设计指导。

AI代码审查的革新

从人工瓶颈到自动化守护

高速度带来的最大挑战是代码审查。团队三人每人每天产出3-5个PR，合并冲突极其痛苦。解决方案分两步：

1. 树状化代码结构，减少冲突概率
2. 缩短PR开放时间，而这需要自动化审查

团队设立了"垃圾回收日"（每周五），专门将一周内观察到的代码问题系统性地消除。他们将审查反馈按角色分类（前端架构师、可靠性工程师等），为每个角色创建Review Agent，在每次push时自动触发。

持续改进的闭环

这形成了一个闭环：人类在PR上给出反馈 → 识别为代理的上下文失败 → 写入仓库文档 → 自动Prompt注入代理 → 代理自我修正。随着文档不断积累，代码质量持续提升，人类需要介入的频率越来越低。

这一闭环机制在本质上实现了组织知识的持续编码化。传统软件团队中，资深工程师的经验往往以口头传授或代码审查评论的形式存在，新成员需要数月才能内化这些隐性知识。而在线束工程中，每一次人类反馈都被转化为机器可读的永久性文档，相当于团队的"制度记忆"以指数速度增长，且永不遗忘。

未来愿景：代码是可丢弃的构建产物

LLM作为模糊编译器

Ryan明确表示：代码是可丢弃的构建产物。线束工程中的所有约束和优化，本质上类似于LLVM编译器中的静态分析和优化pass。更换模型就像更换代码生成后端——只要约束结构正确，不同模型都能产出可接受的代码。

LLVM是现代编译器基础设施的事实标准，其核心设计是将编译过程分为前端（语言解析）、中间表示（IR）优化和后端（目标代码生成）三个阶段。不同编程语言共享同一套优化pass和代码生成后端。Ryan将线束工程类比为LLVM，意味着人类编写的约束、规范和架构文档相当于"中间表示"，而不同的大模型（GPT-4o、Claude、Gemini）相当于不同的"代码生成后端"。这一类比暗示了一个深远的趋势：软件工程的核心产物将从代码转向约束规范，代码本身变成了可再生的编译产物。

终极目标

Ryan描述的未来是：给定Token预算和半年到一年的工作量，加上人类对优先级和成功指标的输入，让机器持续推进产品，而人类完全不需要手动操作。

他强调，软件工程远不止写代码——还包括用户反馈分类、告警处理、PII泄露检查、运维手册编写等。当代码生产不再需要人类参与时，人类的注意力可以转向这些更高层次或更"模糊"的活动，而代理同样能够胜任这些工作。

给从业者的实践建议

对于刚开始使用编码代理的工程师，Ryan给出两条路径：

1. 先用代理写测试——提升对现有代码的信心，同时增强代理后续导航代码库的能力。测试代码是AI代理最容易上手的切入点，因为测试的输入输出明确、质量容易验证，且测试本身会成为代理理解代码库行为的"地图"，为后续更复杂的任务奠定基础。
2. 审视时间花在哪里——等待测试？等待审查？CI太慢？用代理逐步自动化这些耗时环节

最后一条金句值得铭记："每次你需要对代理输入continue，都是线束未能提供足够上下文的失败。"这就是线束工程的终极标准——让系统自驱动，让人类真正成为掌舵者而非划桨者。

核心要点