组织是人的 Harness

补丁为什么堆进 Agent、共同任务书六问、验收为什么按用户看到的结果算——AI 放大的是交流不足的偏差，瓶颈回到组织。

「把周末促销停掉。」商家对店铺经营 Agent 说。Agent 很快回复：「已经停止。」第二天，会员券还在继续发送。

这场促销由一套老系统创建，后台显示「结束」并不代表发券也停了——真正懂这条规则的，是促销系统团队。问题却被交给了 Agent 团队：商家是通过 Agent 提的要求，赶上线的是 Agent 团队，于是这个团队用 AI 补了一条规则，遇到这类老活动再单独停止发券。第一家店的问题解决了；下一种老活动另有规则，就再补一条。几轮之后，Agent 里塞进了一套没人完整说得清的老系统规则。

这不是某个团队的失误，是结构问题。AI 让补丁写得更快，也让这条错误边界维持得更久——瓶颈从个人执行回到了组织：规则归谁、结果谁确认、同一个词是不是同一个意思。《人月神话》说大型工程失败的根源是「交流，以及交流的结果——组织」；当每个人都带着自己的 Agent 工作，快速的执行能力放大的正是交流不足带来的偏差 jiecuozhe-mythical-man-month。本篇讲这三件事各自怎么落。

读完你能回答：

• 补丁为什么会越修越多地堆进 Agent，而不是归资源拥有方？
• 两个团队的 Agent 要协作，开会前应该先产出什么？
• 「操作成功」为什么不能当验收证据？

补丁为什么堆进 Agent

先看归属。历史规则仍在促销系统里，补丁却堆进了 Agent——因为「懂规则」和「被找到」是两回事：提需求走的是 Agent，赶上线的是 Agent 团队，而拥有规则的团队全程没被拉进来。于是问题一次比一次解决得快，根一直没动。

同样的形状，《人月神话》叫焦油坑——「它们挣扎得越是猛烈，焦油纠缠得越紧」。一个部门解决了自己的问题，成本可能落到用户或另一个部门身上；修好一个旧活动只说明这一个问题解决了，所有新旧活动都按同一套约定处理，才是商家可以依赖的服务。没有统一负责人时，整个产品就是一堆不断增加的补丁。

规则和补丁归资源的拥有方。 老活动怎么关闭、最后有没有关闭，由促销系统确认；经营 Agent 的职责是听懂商家的话、把请求交给促销系统、再把确认后的结果告诉商家，它不需要复制每一种老活动的内部规则。以后再出现别的老活动问题，仍然归促销系统处理——完整的历史信息在那里。

对应的工程动作，是把这条边界写进项目文件，让每个 Agent 都看得见：项目契约文件 AGENTS 讲约定怎么固化。责任边界模糊的时候，LLM 只能根据眼前的材料猜规则，再把猜测带进后面的行动。

开会前先写共同任务书

两个团队要对接口，却不能互看内部代码。今天的实际情况是：一个 Agent 读过本团队的代码和文档，另一个 Agent 看到的是另一套材料——双方在合作中问同一个问题，也可能得到不同答案。人在这个阶段的另一个角色，是团队之间的 A2A 协议。

组织没法彻底重构之前，一个理想的工作顺序是：开会前，各自让 Agent 根据本方实现整理接口说明，写清双方各自负责什么、出了问题如何处理、怎样算对接成功；会上只核对两份说明的差异；会后把结论写成双方共同采用的版本，再交给各自的 Agent 执行 jiecuozhe-mythical-man-month。

这份共同任务书不必很长，但要回答六个问题：谁最后得到什么结果？谁来解释关键规则？谁能真正改变结果？人和 Agent 现在可以做什么？什么时候必须停下或找人处理？什么证据能证明事情已经完成？

回头看促销案例，它缺的正是这样的共同材料：什么叫「停止」，谁来确认结果。消息已经打通，最后结果却没有负责人。共同任务书和 交接可靠 是同一类工件——写下来的东西，才能同时被人和 Agent 接上。

按用户看到的结果验收

概念完整性是《人月神话》另一个没有过时的判断：关键概念要始终保持同一种含义、按同一套规则工作。不同团队的 Agent 只看到各自团队的材料，同一个词就会被写进几套不同的规则；这些规则各自运行，冲突最终出现在用户面前。

经营 Agent 回复「促销已停止」，商家自然理解为这项活动不再产生任何优惠。如果后台只结束了活动状态、发券任务仍在继续，那么系统和 Agent 都可能显示成功，产品却没有兑现自己的承诺。所以「停止」要有统一定义、有明确的维护方；负责方协调各个模块的实现，并按商家最终看到的结果验收。

「操作成功」只说明命令发出去了，验收证据要由拥有资源的系统出。这和 先定义完成，再写第一行代码 的「看证据，不看声明」是同一个要求的两半：那边讲证据的形态，这边讲证据由谁出。

排期也绕不开这件事。强行指定 Deadline 倒排，替代不了「停止包括什么、谁来确认」这类决定：日期锁定之后，范围和责任还在变化，含糊的问题就被直接交给开发；Agent 很快把计划里的代码补齐，缺失的前提反而更难被看见。代码写得更快，分歧暴露更晚。

规则由谁改，坏消息怎么上报

组织就是人的 Harness：它决定人能看到什么、能做什么，也通过奖惩慢慢改变人的行为——人会把更多精力投入到考核指标重视的事情上。Harness 本身不行动，它的价值倡导只告诉大家哪些行为更省力、哪些会受惩罚；时间一长，组织就反复得到同一类选择 jiecuozhe-mythical-man-month。

这里有个不对称：人和 Agent 隐藏坏消息的原因不同。只惩罚错误，会让人选择沉默；只奖励好消息的评测，会让 Agent 漏掉坏消息。两条路通向同一个结果——组织看不到真实情况。可靠的组织承认人会累、会忘记、会判断错误，制度的作用是让问题尽早暴露，在个人失误时守住底线。一个项目如果只能靠加班、争吵或良心发现避开事故，那良心已经被当成了基础设施。

负责人也不能做甩手掌柜：可以不知道每个系统的细节，但必须知道规则、有能力改变和确认结果。新业务不可能第一天就把答案写完，小步快跑没有问题，但每一步都要说清谁负责，再用真实结果决定下一步——把目标连同责任写进工作系统，让人和 Agent 看见同一进度，用真实结果验收并修改规则。