Agentic 软件工程使人类上下文成为瓶颈

Agentic 软件工程正在将账单转向人类上下文。

代码来得更快了，Pull Request 堆积得更快了，验证工作落入了越来越庞大的判断工作中，而这些工作仍然需要由人来处理。

这一感受已被 Honeycomb 的 Douglas Soo 在其 8 月 3 日的文章《LLM 驱动的开发：高级工程师的上下文切换之殇，以及初级工程师的成长焦虑》中捕捉到。他写道，虽然 Agentic 软件工程有潜力增加工程团队开发的软件数量，但也存在着一边交付更多软件、一边却对正在开发的软件理解更少的风险。他写道，在 LLM 驱动的开发中，"上下文传递"成为工程循环中代价高昂的一环。旧的软件开发生态节奏——设计、实现、验证、运营（DIVO）——在 Agentic 软件工程新的设计、实现和验证节奏中，实现时间被压缩了。

生成式 AI 软件开发首先消耗人类上下文

旧的软件开发流程倾向于实际实现软件所需的时间。因此，团队做了少许设计之后，会花较长时间为该设计编写代码，然后会有代码审查来验证软件作者编写的代码是否适合真实流量。之后软件会上线，然后团队监控运营问题，而这些又会用于后续版本软件的设计、实现、验证和运营。软件开发的这一过程被称为 DIVO，即设计（Design）、实现（Implementation）、验证（Validation）、运营（Operation）。

软件开发中的这一变化很重要，因为便宜的环节（实现）和稀缺的环节（上下文）已经互换了位置。

实现阶段在缩减，但上下文和验证循环却变得更重了。

正如我们之前概述的，上下文的角色也扩展到了设计层面。因此，在 Agentic 软件工程项目的边界内，Agent 只能处理预先存储并在文档、测试、traces、ticket 条目、评论、示例和仓库整体代码结构之间关联的上下文量。之后，高级工程师实际上必须围绕所有这些 Agent 和上下文重新构建 Agent 形态的系统。

因此，这是一个有架构支撑的工程文化问题，限制性资源不再是击键次数，而是判断力向模型及从模型的转移。

成本模型终于有了名字

故事点一直都有些模糊。Agentic 软件工程让它们更加模糊了。

在《Agentic 软件工程成本估算模型》论文中，ACEM 作者指出，传统的成本模型（如 COCOMO II、功能点和故事点）假设软件成本主要是跨越设计、编码和测试的人工劳力。随着软件开发变得更加 Agentic，人力 effort 转向规划、指定、架构设计和验证 Agent 输出，而预算则吸纳了 LLM tokens、人在环（human-in-the-loop）监督和编排基础设施。

这个框架很有用。首先，LLM 的 token 消耗成本很容易量化。然后，人类监督的成本可以通过声称现有审查流程已涵盖这一点来搪塞过去。最后但同样重要的是，所需基础设施的成本可以隐藏在 Agentic 软件工程工具链以及所有额外层中，如沙箱、评估运行器、trace 存储、路由层、CI 分钟数和权限层。更恰当的说法是，通过提出修订因素（Revision Factors）、上下文因素（Context Factors）和人在环强度分数（HITL Intensity Scores）来描述 Agentic 软件工程成本估算的乘数。

Token 消耗只是 Agentic 工程账单的一层。

是的。ACEM 论文还很早期，其中有些常数只是符号表示。重要的是，作者声称论文中提出的成本估算模型尚未根据真实项目数据进行验证，这一点值得重申，以防止他人以错误的方式使用这项工作来过早估算 Agentic 软件工程的成本。

不要假装以下成本不存在，开始在组织内测量它们。

还要注意，改变方向的重试次数（而不仅仅是重复相同操作的重试）会相对较高。发现产品理解误解的审查轮次也会相对较多（而不仅仅是简单的语法错误）。高级工程师花费大量时间解释为什么一个"更简洁"的抽象实际上违反了操作不变量，这种情况也会很多。还有很多情况下，审查者无法批准变更，因为相关分支没有相关的 traces、截图、迁移计划或回滚计划（即他们无法理解这个变更）。

这些才是 Agentic 软件工程的真正成本，这些成本应该被纳入 Agentic 软件工程的预算中。

上下文传递是运行时状态

Agent 也利用组织状态来生成代码。

据我所知，这是上下文压缩理论论文中给出的问题描述的形式化版本。请注意，在对由编码 Agent 执行的任务进行建模时，模型调用具有有限的上下文窗口。因此，Agent 必须在处理任务时压缩它们积累的上下文状态。它们通过选择部分状态并生成摘要，或者直接生成摘要来实现这一点。上述论文中建模的两种博弈是上下文选择博弈（Context Selection Game）和上下文生成博弈（Context Generation Game）。然后可以将生成与单向通信复杂度关联起来。

这听起来很抽象，因为它确实抽象。但仍然有用。

每个团队已经在运行人类版本的这个游戏了。高级工程师参与讨论，提出"这里什么才是重要的？"这样的问题，并帮助将讨论引向正确的方向。审查者决定打开哪些文件、信任哪些日志，以及哪些产品边界情况看起来有问题。在编写 PR 描述时，决定在 ticket 中放入什么以及从聊天中删除什么，团队正在对什么重要、什么不重要做出决定。

过时的系统知识是有代价的。我们已经确定了文档漂移如何影响编码 Agent 的使用，但同样的文档漂移也影响着同一工作流中的人类。因此，基于对当前系统的不良表示的 Agentic 编码工作流将导致问题，不仅对 Agent 如此，对同一工作流中的人类也是如此。Agent 遵循过时的 README。审查者的脑海中是实时系统的当前状态。初级工程师做 diff 来找出发生了什么变化，却学到了一条实际上是错误的新规则。

这正是 Agentic 软件工程可能变得令人不安的地方。一个团队可能能够产生更多代码，但同时却减少了团队的共同理解。这样的团队的吞吐量图表可能看起来很棒，但当实时系统提出一个没人能回答的问题时，问题就出现了。

将上下文作为构建产物

在工作发生的地方打包上下文。

所以，我们不再把文档当作繁琐的实现细节，而是将反复出现的人类解释转化为 artifacts（如上所述）来支持 Agentic 工程循环。

这也是 LLM 时代人性化的结对版本。Honeycomb 认为，基于 LLM 的开发将结对从一起敲代码转向了"快速反馈"风格的快速设计和验证，高级工程师展示判断力，初级工程师驱动实际实现。这比生成大量 PR，然后在它们进入队列并远远落后之后阅读每个上面的评论要好得多。队列式审查评论不是导师指导，仅仅因为 diff 来自 Agent。

一种技术方法是编写一个'AtumAI'风格的 Agentic 方法来生成数据中心控制平面策略。这种方法首先会将自然语言目标编译为目标、约束、决策变量和评估方法的形式化规范。然后会在形式化问题中搜索解决方案。在对这类方法的评估中发现，在 AtumAI 的评估中，Agent 生成的数据中心控制平面控制策略在各种指标上优于专家手工工程的策略，这些指标用于工作负载放置、计算机资源扩展和数据中心电力管理。

这是一个狭窄的测试，但它说明了一个重要的观点。一般来说，Agent 获取的关于其运行环境的信息越多，它的表现就越好。例如，当给 Agent 的 prompt 不如规范那么好时，情况尤其如此。精心措辞的 prompt 不如评估那么好。diff 的英勇审查者不如记录变更为何安全的工作流那么好。

当一种模式重复出现时，将行为提升为确定性执行。我之前曾指出，当形状已知时，探索应该转变为直接的编码工作。同样的事情也适用于工程文化。如果高级工程师第三次解释同一个操作不变量，就不要再燃烧高级注意力在重新发现上了。把这个不变量放入代码、测试、Agent 指令和审查检查中，以便再次找到它。

所有权通过显式化得以延续

Agentic 编码意味着分支蔓延和所有权弱化。

更好的交易是平淡无奇的。更少的断开连接的工作流。更强的交接 artifacts。实时 traces 反馈到下一个 prompt、测试和验收标准。审查要问代码是否满足产品意图、是否安全运行，以及工作是否捕获了足够的学习以使下一次运行更便宜。

过程证据在这里很重要。关于 Agentic 商务的 ACWorld 论文发现，仅最终状态可能遗漏评估的错误，而不完整的轨迹仍然包含有用的信号。其环境在共享状态更改之前验证操作，并记录交互以进行可重现的持续事务评估。软件团队以不那么花哨的形式有同样的问题。绿色合并是一个最终状态。有趣的证据存在于路径中：Agent 尝试了什么、审查者拒绝了什么、哪个假设改变了、哪个 trace 证明了修复、哪条回滚路径存在。

使用 Agent 进行软件工程将奖励那些将流程中的人类上下文视为稀缺运行时输入的团队。因此，它应该花在必要的地方，即需要高质量判断的地方。所有其他未来需要类似解释的情况都可以通过将它们转化为 artifacts 来保存，这些 artifacts 可以被 Agent 使用，也可以被人类用于验证。

实现速度快到在软件工程预算中只值得一行字！