Multi-Agent Coding Isn’t Enough — Agents Need a Commitment Layer

多智能体编程还不够——智能体需要一个“承诺层”

TL;DR When multiple AI coding agents talk to each other, they can still duplicate work, get the task order wrong, and waste time. Text chat alone isn’t enough to keep them on the same page. 简而言之： 当多个 AI 编程智能体相互交流时，它们仍然可能重复工作、搞错任务顺序并浪费时间。仅靠文本聊天不足以让它们保持步调一致。

To solve this, I built the ledger around a simple idea. If an agent says, “I’ll build the items file,” I record that as a commitment instead of leaving it buried in the chat. The implementation is just Python’s standard library. No database, API, or external package is involved. In my test case, using the ledger avoided duplicate work and dependency-notification failures. It didn’t fix cases where an agent failed to finish a job or reported work without verification. 为了解决这个问题，我围绕一个简单的想法构建了“账本”（ledger）。如果一个智能体说：“我来构建 items 文件”，我会将其记录为一项“承诺”，而不是让它淹没在聊天记录中。该实现仅使用了 Python 标准库，不涉及任何数据库、API 或外部包。在我的测试案例中，使用账本避免了重复工作和依赖通知失败。但它无法解决智能体未能完成工作或在未经核实的情况下报告工作的情况。

That was the key takeaway: a ledger can improve the coordination state, but it can’t force an AI agent to follow through on its work. 这就是核心结论：账本可以改善协调状态，但它无法强迫 AI 智能体真正完成其工作。

Why Coordination Fails Even When Communication Doesn’t 为什么即使沟通顺畅，协调依然会失败

A team from Stanford and SAP Labs recently published CooperBench, a benchmark for testing whether coding agents can work as teammates rather than as separate solo workers [1]. In the setup, two agents work on the same codebase, each gets a feature, the features can conflict, and the agents can communicate while they work. 斯坦福大学和 SAP Labs 的团队最近发布了 CooperBench，这是一个用于测试编程智能体能否作为队友协作，而非作为独立个体工作的基准测试 [1]。在设置中，两个智能体在同一个代码库上工作，每个智能体负责一个功能，这些功能可能会产生冲突，且智能体在工作时可以进行交流。

The result caught my attention. The cooperating agents did not consistently perform better. In the benchmark, cooperating pairs scored worse than a single agent handling the same total workload [1]. 结果引起了我的注意。协作的智能体并没有表现得更好。在基准测试中，协作对的表现甚至不如处理相同总工作量的单个智能体 [1]。

Communication analysis is also important. The paper reports vague or badly timed messages, incorrect assumptions about what another agent is doing, and cases where agents drift away from commitments they had already made [1]. 沟通分析同样重要。论文指出，智能体之间存在模糊或时机不当的消息、对其他智能体行为的错误假设，以及智能体背离其已做出的承诺的情况 [1]。

That last part is what led me to this project. 最后一点正是促使我开展这个项目的原因。

I don’t mean that an agent “forgets” in the human sense. The problem is simpler. An agent can say, “I’ll implement repository/items.py,” and a few messages later there may be nothing outside the conversation that records that decision. Another agent can make the same claim. A dependency can be missed. A completed task can be reported without any separate record showing whether it was actually verified. 我指的并不是智能体在人类意义上的“遗忘”。问题更简单：一个智能体可以说“我来实现 repository/items.py”，但在几条消息之后，对话之外可能没有任何记录该决定的地方。另一个智能体可能会提出同样的要求。依赖关系可能会被遗漏。一项已完成的任务可能会在没有任何独立记录证明其是否经过核实的情况下被上报。

The paper also found cases where agents did coordinate successfully. In a minority of runs, agents divided roles, split resources, or negotiated scope without being explicitly instructed to do so [1]. So coordination is possible. The problem is that it isn’t reliable. 论文还发现了一些智能体成功协调的案例。在少数运行中，智能体在没有明确指令的情况下分配了角色、划分了资源或协商了范围 [1]。因此，协调是可能的，问题在于它不可靠。

That gave me a much narrower question to test: What happens if I take an agent’s commitments out of the conversation and give them somewhere to live? 这让我提出了一个更具体的测试问题：如果我将智能体的承诺从对话中提取出来，并为它们提供一个存储空间，会发生什么？

That’s what I built with the Commitment Ledger. It is a small deterministic system that records multi-agent coding commitments as explicit state and checks that state for conflicts, dependencies, missed work, and rework. 这就是我通过“承诺账本”所构建的东西。它是一个小型确定性系统，将多智能体编程的承诺记录为显式状态，并检查该状态是否存在冲突、依赖问题、遗漏工作和重复劳动。

Full code, tests, and logs are below. https://github.com/Emmimal/commitment-ledger/ 完整代码、测试和日志见下方链接： https://github.com/Emmimal/commitment-ledger/

What I Wanted the Ledger to Solve 我希望账本解决什么问题

I wasn’t trying to solve every multi-agent failure. I wanted to isolate one specific problem: a commitment exists in the conversation, but another agent has no persistent state to check before taking the same work. 我并不是要解决所有的多智能体故障。我只想隔离一个具体问题：对话中存在一项承诺，但另一个智能体在接手同样的工作前，没有持久化的状态可以查询。

I’ve seen how this can happen when multiple AI agents work against the same codebase, even when the agents are running in separate terminal sessions and coordinating through a shared document. The failure doesn’t announce itself as a coordination bug. It shows up as, “Wait, didn’t you already do this?” three turns after the duplicate work happened. Or you discover that a merge has quietly overwritten something another agent finished an hour earlier. By the time you notice it, the wasted work has already happened. 我见过当多个 AI 智能体在同一个代码库上工作时，即使它们在不同的终端会话中运行并通过共享文档进行协调，这种情况也会发生。这种故障不会以“协调错误”的形式显现，而是在重复工作发生三轮之后，才表现为“等等，你不是已经做过这个了吗？”或者你发现一次合并悄悄覆盖了另一个智能体一小时前完成的工作。当你注意到时，工作已经白费了。

This isn’t for a single agent. There is no coordination state to track. It also isn’t needed when agents already have strictly partitioned, non-overlapping file ownership, because that solves the conflict problem before it starts. 这不适用于单个智能体，因为没有需要跟踪的协调状态。当智能体已经拥有严格划分、互不重叠的文件所有权时，也不需要它，因为这在冲突发生前就解决了问题。

And it won’t tell me whether the work is correct. The results below make that limitation pretty clear. 而且它无法告诉我工作是否正确。下方的结果清楚地表明了这一局限性。

Architecture 架构

There is no model call in this pipeline. I built the detector, ledger, and checks as a set of Python rules operating on explicit state. The same input produces the same result every time. 这个流水线中没有模型调用。我将检测器、账本和检查机制构建为一组在显式状态下运行的 Python 规则。相同的输入每次都会产生相同的结果。

System architecture for the rule-based tracking pipeline: By processing the coding-agent conversation through a deterministic Commitment Detector and an immutable Commitment Ledger, the system checks for conflicts and missing dependencies without relying on an LLM. 基于规则的跟踪流水线系统架构：通过确定性的“承诺检测器”和不可变的“承诺账本”处理编程智能体的对话，系统无需依赖大语言模型（LLM）即可检查冲突和缺失的依赖项。

The diagram visualizes the five-step architecture designed to track and evaluate how coding agents coordinate on tasks, built entirely on explicit state rather than model calls. The process begins with the Coding-Agent Conversation as the raw input stream. The data flows into the Commitment Detector, which is explicitly annotated with “Frozen grammar, no LLM.” This highlights its deterministic nature—relying on a strict list of verbs and patterns rather than AI guesswork to extract promises made by the agents. The detector outputs discrete Commitment Events (e.g., COMMITTED, STARTED, IMPLEMENTED). These events are recorded sequentially in the Commitment Ledger, marked as an “Immutable event history.” This design ensures that subsequent errors or duplicate claims by other agents do not erase the original context of a commitment. The ledger’s historical data then branches into two parallel evaluation rules: a Conflict Check (identifying if multiple agents claim the same object) and a Dependency Check (verifying if prerequisites are met). Finally, the findings from these checks converge to generate the Coordination Report, which logs coordination failures like missed dependencies and duplicated rework. 该图展示了五步架构，旨在跟踪和评估编程智能体如何协调任务，完全基于显式状态而非模型调用。流程始于作为原始输入流的“编程智能体对话”。数据流入“承诺检测器”，该检测器明确标注为“固定语法，无 LLM”。这突显了其确定性——依靠严格的动词和模式列表，而非 AI 的猜测来提取智能体做出的承诺。检测器输出离散的“承诺事件”（如 COMMITTED、STARTED、IMPLEMENTED）。这些事件按顺序记录在“承诺账本”中，标记为“不可变的事件历史”。这种设计确保了后续的错误或智能体的重复声明不会抹除承诺的原始上下文。账本的历史数据随后分支为两条平行的评估规则：冲突检查（识别多个智能体是否声明同一对象）和依赖检查（验证先决条件是否满足）。最后，这些检查的结果汇聚生成“协调报告”，记录诸如依赖缺失和重复劳动等协调失败情况。

The ledger checks for five failure modes. Each one is derived from the records already stored in the ledger. Nothing comes from an agent’s own report, and there is no manual judgment involved. 账本会检查五种故障模式。每一种都源自账本中已存储的记录。没有任何信息来自智能体自己的报告，也不涉及任何人工判断。

Component 1: The Commitment Detector 组件 1：承诺检测器

I could have used an LLM to extract commitments, but that would add another moving part to the experiment. The detector would depend on a model call, and the results would be harder to reproduce. I wanted to test the ledger itself. 我本可以使用 LLM 来提取承诺，但这会给实验增加另一个不确定因素。检测器将依赖于模型调用，结果将更难复现。我想要测试的是账本本身。