用ACDL组织人与Agent协作

写得快以后，怎样保持方向清楚

Agent可以连续调查、修改代码、运行测试和参与评审，也可能在目标模糊时迅速做出一套复杂实现。多人和多个Agent并行后，还容易出现设计、代码、测试与运行情况各说各话的问题。

蜂巢把自己的协作方法称为ACDL，即Agent Collaborative Development Lifecycle，中文为“Agent协同研发体系”。它依据项目实际需要组织需求、设计、实施、检查和交付，不是行业标准，也不是某款编程工具的专用操作法。

把长期事实放在能查到的位置

对话适合讨论，不能独自承担项目全部记忆。需求解释为什么改变，设计约定系统怎样工作，实际记录说明做了什么，版本说明确定交付了什么。各类资料分别保存事实，其他地方做摘要并链接，避免一项决定在多处出现不同版本。

所谓“文档作为代码的源码”，是让后续Agent能够找到当前依据，不是要求所有文字先于实现写完，更不是以页数衡量严谨。进入任务时只读与目标有关的规则、文件和证据，不从历史搜索结果推翻当前设计。

按实际影响选择工作路径

工作类型	主要做法	需要证明什么
边界清楚的普通维护	明确目标，直接修改并检查	原问题解决，相关行为没有被破坏
新增能力或长期规则变化	先整理需求与必要设计，再实施	重要取舍已有依据，权限与数据含义清楚
事实不明的故障	先复现、调查并保留现场	找到原因，恢复动作没有扩大影响
准备正式交付	固定候选，完成相应验收与版本记录	交付范围和已知限制可追溯

文件少不表示风险低。一行权限代码可能需要完整设计和独立评审；许多文件的机械修正也可能只需要清楚范围和适当检查。流程长度由实际影响决定，不把全部步骤机械套在每项工作上。

多个Agent围绕任务协作

负责人Director对方向、重要取舍和结果负责，这是一种责任角色，不是公司职级。Agent在明确目标和权限内调查、实现、验证并带回证据；新出现的重要产品决定或高风险动作需要负责人判断。

并行工作的单位是可独立验证的任务。每项任务要有范围、起点、独占文件或接口约定，以及验收方式；固定候选接受评审时，应停止继续写入。作者换个会话进行自查，仍然不能替代未参与实现者的独立评审。

区分几种“完成”

代码写完、自动检查通过、真实使用验证和正式版本形成，回答的是不同问题。ACDL分别使用ACL描述需要持续记录的实施工作、DFL描述真实使用反馈、ERL描述独立工程复核；它们不是每次必走的串行关卡。

结果报告应说明改了什么、检查了什么、哪些失败或尚未验证。演示与测试替身不冒充真实业务验收，合入主线也不自动等于正式发布。这样的区分帮助后来接手的人判断结果，同时保留按风险调整流程的空间。