# 奥卡姆很忙 当 Agent 能够读取环境、协调工作并参与修订契约，许多为低速执行和上下文断裂建立的结构都需要重新证明价值。更难省略的，是目标、边界、证据、记忆与回退。 ## Metadata - HTML: https://glenzli.com/notes/occam-is-busy/ - Markdown: https://glenzli.com/notes/occam-is-busy.md - Collection: Notes - Language: zh-CN - Published: 2026-07-26 - Updated: 2026-07-26 - Tags: ai, software-engineering, agents, architecture, protocols, judgment ## Content 最近，我在尝试让多个 Agent 同时参与一个复杂桌面应用的开发，高并发地推进不同部分。 多个 Agent 如何协作，正在成为一个很受关注的问题。常见的做法是先定义 A2A 协议，规定消息格式、任务状态、调度方式和冲突处理。 我一直不太热衷于在协作真正发生以前，就把这些细节定义完整。 缺少具体场景时，我们能够预想到的往往只是角色、消息、状态和调度这些通用问题。它们并非没有价值，却很容易停留在泛泛的框架里。真正影响协作的细节，往往要等参与者进入同一个项目，开始修改同一批文件以后才会显露出来。 这不是拒绝协议，而是认为第一版不必替还没发生的协作把所有细节定死。 所以这次我没有先替 Agent 写好一套完整协议，只给出了最初的关系和边界：你们需要共同完成这个项目，其他 Agent 是协作者；先基于当前项目维护一份初始契约，再根据实际工作中出现的问题修正它。 契约里只有几条基本共识。大家服务于同一个目标，共享文件中的修改会影响其他协作者，发生重叠时需要调整，完成任务以后要留下可以检查的结果。 至于任务如何声明、共享文件怎样处理、什么时候需要额外沟通，并不要求第一版契约全部覆盖。这些规则可以在协作中形成，也可以在需要时被明确记录和修正。 ## 协调不必发生在工作之外 这里所说的协调，并不是让 Agent 分别扮演产品经理、架构师和工程师，再模仿人类开会。 人类团队需要会议、汇报和明确的角色分工，很大程度上是因为每个人掌握的上下文不同。协作需要暂时离开工作对象，通过语言重新拼出彼此已经做了什么、正在做什么、接下来准备做什么。 Agent 面对的条件有所不同，但也并非没有限制。 在权限和环境允许时，它们可以读取同一个代码库、任务状态、测试结果和变更历史。从工作声明中可以看到其他协作者正在处理的范围，从补丁中可以看到实际意图，从测试结果中可以获得比口头汇报更直接的证据。 发现重叠以后，Agent 可以先查看差异，再决定调整任务还是继续合并。共享状态不足以得出结论时，额外的信息交换仍然必要。 今天就遇到了一个具体情况。两个 Agent 的工作发生冲突，一方持有的锁暂时阻断了另一方。若在一开始把流程设计得很完整，很容易为这种情况加上轮询、超时和中止等待任务的规则。实际运行时，等待的一方利用了 Codex 现有的跨任务通知能力：状态变化后收到通知，随即恢复工作，既没有轮询，也没有退出。这条路径并没有解决所有恢复问题，却比预先设想的流程更合适，因为它利用了环境里已经存在的能力。随后，Agent 又为不同类型的冲突形成了更细的交接方式：一方只需要轻量修改，而另一方会长期占用同一范围时，前者可以直接把任务转交出去；一方需要占用文件，但另一方仍有未完成需求时，也可以主动申领那部分需求并一并处理。这些不是预先写好的角色分工，而是根据修改粒度、占用时间和共享状态临时形成的约定。 运行也同时暴露了这套做法的边界。在目前的 Codex 环境中，跨任务消息只对仍在运行的 Agent 有效；其中一个任务已经停止时，消息不能把它重新接上，工作也不会沿着这条链路自动续接。因此，人工判断和介入仍然不可少：哪些状态必须持久记录，什么时候该等待，什么时候要为中断准备显式的接续方式。这个反例没有推翻前面的判断，反而让它更具体：先利用环境中实际存在的能力，再让暴露出来的限制推动下一轮设计。 这当然不是一条通用的 A2A 结论，也不是说冲突处理不需要设计。它更像一条设计原则：该提前确定的是冲突时不能牺牲的边界、需要被保存的状态，以及高风险操作的确认条件；至于通知、等待还是交接由什么机制完成，则不必在还不知道环境、负载和失败方式之前就写死。 因此，Agent 之间的协调不一定表现为一段对话。 一次工作范围的更新、一份补丁的调整或者一个新的测试结果，都可能已经完成了必要的信息交换。协调可以嵌入工作本身，不必总在工作之外复制一套人类组织的会议和汇报制度。 我也没有退出这个过程。Agent 的反馈有时会暴露契约里缺失的部分，我会参与修正，并决定哪些边界不能随着一次局部协作改变。 随着项目推进，契约逐渐显出两个有用、但并非严格分开的层次。 任务声明、交接方式和局部协作习惯可以调整。共同目标、权限范围和高风险操作的确认条件则需要保持稳定。 前一类规则服务于当前协作，可以根据实践改变；后一类规则承担现实后果，不能只靠参与者临场商量。同一个具体结构往往同时承担两类职责，不能只因名称而被简单归类。 A2A 协议当然有适合它的场景。协作跨越厂商、组织和信任边界时，标准化的身份、权限、消息来源和失败语义非常重要。但在共享代码库和共同目标的环境里，协议需要详细到什么程度，更适合由已知的风险、环境约束和实际出现的问题共同决定。 这个案例没有证明协议可以消失。 它只是说明，在参与者能够读取环境、解释目标并根据结果调整行动的条件下，一部分秩序可以从实践中形成，不必全部提前固化。 ## 同一条线上的变化 从这个案例往外看，最近关于 AI 软件工程的许多变化，其实都在触碰同一个问题。 实现成本下降以后，过去为了避免返工而设置的完整前置流程需要重新衡量。反馈速度提高以后，需求、开发和使用不必始终保持固定顺序。Agent 成为软件用户以后，界面、说明书和初始流程也不再完整限定软件的实际用法。模型本身也一样：权重可以相同，但进入不同的上下文、工具和协作方式，它实际呈现出的行为会明显不同。流程设计因而不只是在交付一套人或 Agent 必须照着执行的步骤，也在塑造哪些行动更容易发生、哪些行动更难发生的环境。模型能力继续变化，为暂时缺口建立的脚手架则可能很快过期。 这些变化的共同点，不是某种软件结构突然失去了价值，而是支撑它们的条件发生了变化。 很多结构原本用来应对昂贵的实现、缓慢的反馈、断裂的上下文和解释能力有限的组件。它们有明确来历，也确实解决过问题。 条件改变以后，结构需要重新说明自己还在承担什么。 多 Agent 契约里的那两个层次，在这里仍然适用。有些结构主要负责组织当前方法，可以随着环境变化；有些结构主要保护事实、权限和实际后果，需要保持稳定。它们有时也会重叠。 决定一项结构去留的，不是它叫 API、流程、文档还是架构，而是它现在属于哪一类。 ## 看职责，不看名字 同一种结构往往同时承担多种职责。 文档可能只是在重复代码里已经存在的信息，也可能保存无法从当前状态重新推导的历史决定。工作流可能只是把任务塞进固定顺序，也可能承担责任分配、风险确认和审计要求。Schema 不仅帮助系统交换数据，也让数据含义能够跨越团队和版本保持稳定。 因此，不能因为 Agent 可以阅读代码，就认定文档已经没有价值；也不能因为自然语言能够表达意图，就把确定性接口都换成临场理解。 形式本身不能决定去留。 如果确认参与者能够稳定获得同样的信息，一个结构若只是在搬运这些信息，就可以缩小、临时生成，或者直接结束。 如果它仍在保护边界、保存证据或者承担责任，就有继续存在的理由，有时还需要比过去更加清楚。 ## 刀落下以后，还应该留下什么 把具体形式暂时放到一边，真正难以省略的职责并不多。 首先是目标和判断。系统需要知道为什么行动，哪些结果值得保留，什么时候应该继续，什么时候应该停止。执行越来越便宜以后，判断不会变得次要，反而决定高速生产是否只是在重复已有模式。 其次是权限和边界。执行者越有能力，一次误判可能影响的范围越大。哪些数据可以读取，哪些系统可以修改，哪些操作必须由人确认，不能建立在“它应该能理解”之上。 事实、证据和必要的历史也需要留下。参与者需要知道什么已经发生，什么可以相信，以及一个决定为何形成。代码、测试、运行记录和实际状态，通常比参与者对过程的描述更可靠。 最后是回退和责任。只要理解可能出错，系统就需要让错误可以被发现、隔离和撤销。无法回退的操作需要更严格的确认，出了问题也必须知道由谁承担最终判断。 API、文档、工作流、协议和架构如果仍在履行这些职责，就有存在的理由。 如果它们不再保护任何重要东西，只是因为过去一直如此而继续存在，就应该重新接受检查。 有些结构可能消失，有些可能缩小，还有一些可能从永久设施变成按需生成的临时结构。与此同时，那些直接连接现实后果的边界往往需要变得更清楚。 这并不意味着 AI 会把软件工程带向一个没有结构的世界。 它正在让更多结构失去默认永久存在的资格。 ## 奥卡姆很忙 奥卡姆剃刀从来不是无限删减。 它要求的是，每一个被引入的实体都应该有存在的理由。 AI 时代，这把刀会很忙。既有的软件结构需要重新接受检查，新出现的 A2A 协议、Agent 工作流和模型脚手架，也不能因为带着 AI 的名字，就自动获得长期存在的资格。 一项结构是在帮助参与者组织当前工作，还是在保护不能交给协商的现实边界？ 它保存了无法重新获得的事实，还是只在重复已有信息？ 它来自已经发生的问题，还是来自对所有情况都要提前覆盖的焦虑？ 如果删除会让权限、责任和后果变得模糊，这个结构就有理由保留，往往还需要变得更清楚。 如果系统只是少了一层转换和仪式，它就值得被尝试性地移除。 AI 时代最需要被删除的，不是某一类结构，而是结构免于重新解释自身价值的特权。 最小秩序也不是规则最少。它是让必须提前确定的内容足够清楚，让能够从实践中形成的部分保留变化空间。 所以，当实现、理解和协作的条件都开始改变，软件工程最终需要回答的不是“还要不要 API、流程、文档和架构”，而是： > 它们今天究竟还在保护什么？ ## 相关材料 - [AI 脚手架的半衰期](https://glenzli.com/notes/half-life-of-ai-scaffolding) - [当软件的时间开始松动](https://glenzli.com/notes/software-time-loosens) - [说明书之外](https://glenzli.com/notes/software-beyond-the-manual) - [当速度开始改变探索](https://glenzli.com/notes/speed-matters) - [AI Software Engineering Notes](https://github.com/glenzli/ai-software-engineering-notes)