多Agent协作的边界设计——谁能写代码、谁能改代码、为什么

之前我用5个AI Agent协作开发了一个股票分析软件。**整个过程不到3小时——从一句话需求到1800行可运行代码。每个Agent各司其职CEO拆任务、CTO写代码、CFO管项目、市场总监收集数据、投资专家定策略。但如果你仔细看协作日志会发现一个细节CTO技术总监只负责写新代码从来没有改已有代码。修改代码的操作要么由CEO在审查后执行要么由人工介入。这不是技术限制——AI Agent完全有能力直接改文件。这是刻意的设计。这篇文章就来聊聊这件事多Agent协作中谁能写代码、谁能改代码——以及为什么这个边界决定了你的项目是越来越稳还是越来越烂。一、一个真实的翻车现场先说一个我没写在复盘文章里的细节。在5个Agent协作开发股票软件的过程中有一次CTO写完K线图渲染模块后发现之前写的均线计算函数有个bug——它把MA20算成了MA30。CTO的第一反应是“我直接改掉这个函数。”但从协作架构的设计来看这个操作被拦截了。原因有三1. CTO不知道这个函数有没有被其他地方调用。它只是执行层Worker上下文里只有当前任务的代码看不到全局依赖关系。2. 改一行代码可能引入新问题。均线计算的参数变化会连锁影响后面的技术指标计算、图表渲染、数据导出。3. 如果允许Worker自由改代码第二天你会发现没有任何Agent能理解整个代码库了。每个Agent都在自己的上下文窗口里局部优化全局一致性被破坏。最后是CEOOrchestrator出面先读完所有调用点确认改动范围然后一次性修正均线函数、更新所有调用方、跑完整测试。用时3分钟。这个3分钟的延迟不是低效——它避免了30分钟的连锁排查。二、三层边界模型多Agent协作不是一群AI聊天而是一个受控的工程系统。在我的实践中它分为三层第一层规划层Orchestrator——只规划不执行角色CEO、项目经理、架构师权限读所有代码、拆解任务、分配角色、仲裁争议禁令不能直接写代码、不能直接执行命令为什么因为规划层掌握全局上下文。如果它自己下场写代码就没有人能客观评估代码质量。裁判不能同时是运动员。真实案例Hi3519DV500编译环境搭建时我作为Hermes Agent承担了Orchestrator的角色。我制定了10个阶段的编译方案、编写了6个自动化脚本——但每个脚本在执行前都经过了用户的审查确认。第二层执行层Worker——只执行不决策角色技术总监、开发工程师权限写新代码、跑测试、查资料、执行命令禁令不能修改已有代码、不能改变项目架构、不能绕过审查层执行层Agent的能力最强——它们会写代码、会调库、会用工具。但能力越强边界越重要。真实案例在5 Agent股票软件项目中CTO写了6个Python文件。其中有一次它想优化主窗口的布局逻辑——那个函数涉及到GUI框架的信号槽机制。如果贸然改动可能导致整个界面的事件处理崩溃。规则是Worker可以写新功能但要改现有功能必须提Pull Request由审查层评估。第三层审查层Reviewer——只审查不创作角色Code Reviewer、安全扫描、质量门禁权限读取diff、运行测试、标记问题禁令不能直接修改代码只能提建议这一层最容易因为太麻烦而被省略——但在多Agent场景下它是唯一的质量底线。真实案例公众号文章发布流程。每篇文章写完后的审查步骤1. 内容隐私扫描——有没有出现真实姓名、API Key、IP地址2. 格式修正——有没有微信不支持的编号列表变黑点3. 代码块渲染——div 灰底白字格式是否正确闭合4. AI痕迹清除——有没有本文由辅助撰写、让我们等字样这些审查如果交给写文章的Agent自己做等于让考生批改自己的试卷。三、为什么写代码和改代码需要不同权限这是整个边界设计的核心问题。3.1 上下文窗口不对称一个Worker Agent在执行任务时上下文窗口里装的是当前任务相关的代码。它不知道• 这个函数被几个模块调用• 改动会影响哪些下游系统• 3天前别人为什么这样写• 这段代码是不是在修另一个bug时引入的workaround让一个看不到全局的Agent去改全局代码就像让一个只看了引擎盖下的修理工去调变速箱——他能拧螺丝但不知道这辆车为什么抖。3.2 修改的蝴蝶效应真实案例。在89份PDF批量摄入到LLM Wiki的过程中有一次我发现[[U-Boot 移植]]页面需要更新。如果直接改那个页面看起来简单。但实际上修改 [[U-Boot 移植]]→ 影响了 [[启动配置]] 中引用的移植步骤→ 影响了 [[裸烧与非裸烧升级]] 中提到的启动方式→ 影响了 [[DDR 参数配置]] 中的 U-Boot Table 说明→ 需要同步更新 3 个页面的交叉引用 log.md如果让执行层Agent直接改它大概率只改第一个页面断开另外3条链接。知识网络退化为知识碎片。3.3 所有权混乱这是最隐蔽的问题。当一个代码库被多个Agent修改过后没有任何一个Agent能说清楚为什么这行代码是这样的。修改的Agent早就忘了它当时的上下文。下一个Agent看到这行代码只能猜测意图。猜错了就引入新bug。代码变成考古现场——每个Agent都在解读上一个Agent的意图但谁都没有完整的考古记录。这个问题的解法是修改权的集中化。要么由Orchestrator统一修改要么由人工操作。不允许Worker自由交叉修改。四、真实案例一5 Agent股票软件的边界设计回到开头那个项目。5个Agent的具体分工和边界Agent能做什么不能做什么为什么CEO拆解任务、分配角色、合并结果写代码、执行命令保持全局视角CTO写新代码、跑测试改已有代码、改架构避免局部优化破坏全局CFO项目管理、质量验收修改交付物验收者不能是被验收者市场总监数据收集、测试验证修改分析逻辑数据层不能掺杂分析偏好投资专家策略设计、模型参数直接改数据策略不能看到了未来数据一个具体场景场景CTO写完K线图发现Y轴刻度有问题——价格从0开始导致K线被压扁。错误做法CTO直接改plot_kline()函数把Y轴改成自适应范围。正确做法1. CTO在Todo中标记K线Y轴需优化附上当前输出截图2. CEO审查后确认这是需要修复的bug不是设计选择3. CEO检查 plot_kline() 的调用链——确认改动范围4. CTO提出修改方案改哪些行、为什么5. CFO审查层跑测试验证确认不改坏其他图表6. 修改生效6步看起来很啰嗦但如果不走这套流程——第二步直接跳到第六步——后果是什么真实发生过一次某个Agent改了一个看起来无关紧要的日期格式化函数从%Y-%m-%d改成%Y/%m/%d。结果另一个模块的正则表达式是用-来split日期的瞬间崩了。如果不走审查流程这个bug可能要20分钟后才能发现——那时候Agent的上下文早换了。五、真实案例二Hi3519DV500编译环境搭建的改代码边界2026年6月我辅助搭建了海思Hi3519DV500的完整编译环境。这个过程中写了6个自动化脚本踩了9个坑。其中一个坑特别典型Ubuntu 24.04的pip安装需要--break-system-packages参数。当时脚本01依赖安装已经写完了里面写的是pip3 install meson ninja执行时直接报错——Ubuntu 24.04用externally-managed-environment策略拦截了全局pip安装。如果让同一个Agent直接改这个脚本它会怎么做大概率加上--break-system-packages就完事。但它不会考虑• 这个改动是不是最佳实践apt install python3-meson 更安全• 加了这个参数会不会影响脚本的其他部分• 其他依赖ninja-build、pkg-config是不是也有更好的apt替代方案实际的正确做法1. 执行层Agent跑脚本 → 遇到pip报错 → 汇报2. 审查层人工Agent评估这不是pip的问题是Ubuntu 24.04的策略变更3. 决策不用 --break-system-packages改用 apt install python3-meson python3-ninja4. 更新所有依赖安装策略不只是这一个包5. 更新方案文档记录决策原因6. 生成 check_deps.sh 自动检测脚本避免下次踩同一个坑如果让执行层Agent自己修一下它不会走到第3步——它只看到pip报错看不到系统包管理器的替代方案。六、真实案例三Ingest Pipeline的改知识边界在上面提到的89份PDF→LLM Wiki的Ingest Pipeline中有一个比代码更敏感的修改场景修改已有的知识页面。当新的PDF比如《裸烧及非裸烧升级 使用手册》被摄入时Agent需要判断• 已有页面 [[裸烧与非裸烧升级]] 存在但只有3个段落• 新PDF包含19页详细内容→ 不是创建新页面而是更新已有页面这个更新的边界设计是✅ 可以做的事情• 在已有段落后面追加新内容不删不改原有内容• 添加新的交叉引用 [[wikilinks]]• 在 frontmatter 的 sources 字段追加新的来源引用• 更新 log.md 记录改动❌ 不能做的事情• 删除已有段落可能包含其他来源的交叉验证信息• 重写页面结构可能破坏已有 wikilinks• 修改已有来源标注• 修改其他Agent写入的内容为什么追加而非覆盖因为知识不是代码——代码的旧版本可以直接丢弃但知识的旧来源可能是正确的只是不完整。新来源补充了它但不等于否定它。如果允许Agent自由覆盖三个月后你会发现第一版写的内容全被后面的Agent改没了但你永远不知道是改得更好了还是改丢了什么。log.md的不可变设计就是为这个场景服务的## [2026-06-19] ingest | 裸烧及非裸烧升级 使用手册 - 操作: UPDATE [[裸烧与非裸烧升级]] - 原因: 已有页面只有3段概述PDF包含19页完整内容 - 新增: 烧录流程对比表、失败原因分析、模式选择决策树 - 保留: 原有3段概述未删除三个月后任何人都能回溯这次修改的完整决策过程。七、边界设计的三条铁律从这些真实案例中我提炼出三条铁律铁律一写代码的Agent不能改已有代码理由上下文窗口不对称 修改的蝴蝶效应 所有权混乱操作方式改代码必须经过Orchestrator或人工审查。delegate_task的子Agent只能创建新文件或在指定位置追加内容——不能用patch工具修改其他Agent的输出。铁律二审查必须由不同角色执行理由自审自批 无审无批。考生不能批改自己的试卷。操作方式• 代码审查由不同的Agent或人执行• 安全扫描由自动化脚本执行不依赖Agent判断• 格式检查由规则引擎执行不依赖Agent觉得对不对铁律三任何修改必须有log理由没有记录的修改 不存在。三个月后没人知道为什么改的。操作方式• 代码修改 → Git commit必须带描述性message不能用fix• 知识修改 → log.md 追加不可变日志只追加不修改• 配置修改 → 变更记录改了什么、为什么、影响范围八、什么时候可以放宽边界不是说所有场景都必须走严格的3层审查。有些场景下边界可以适度放宽可以放宽的场景✅ 临时实验项目写完就扔的spike代码✅ Agent自己创建的新文件还没有被其他模块依赖✅ 格式修改不影响逻辑如代码格式化✅ 单Agent独占的项目没有多人协作的冲突风险绝不能放宽的场景❌ 被多个模块依赖的核心代码❌ 已经部署到生产环境的代码❌ 其他Agent也在编辑的同一个文件❌ 知识库中的已有页面❌ 配置文件改错一个参数影响全局九、对比业内其他方案的边界设计来看看业界主流方案是怎么处理这个问题的方案边界设计优点问题Claude Code (Anthropic)人工审批所有文件写入安全可控人工成为瓶颈Codex CLI (OpenAI)默认审批可配置always approve灵活配置失误后果严重Cursor AgentAgent直接写文件人工可回滚速度快回滚成本高本文方案3层边界规划→执行→审查平衡效率和安全需要Agent间通信机制我的方案不是最自动化的——但它是唯一一个在3小时后还能维护的方案。十、给你的实操建议如果你正在搭建自己的多Agent协作系统以下是可以直接拿去用的规则建项目时的初始设置1. 指定一个Orchestrator Agent它不写代码只拆任务、分角色、合并结果2. Worker Agent 只开放 write_file创建新文件禁止 patch修改已有文件3. 任何代码修改走 Mini-PR 流程Worker提方案 → Orchestrator审查 → 确认后执行4. 所有操作记录到 log.md时间、操作者、改动内容、原因5. 安全扫描和格式检查设为自动化规则不依赖Agent主观判断运行中的检查清单□ 这次修改涉及几个文件→ 超过1个 需要审查□ 这个文件被几个模块引用→ 超过0个 需要审查□ 上次修改是什么时候→ 最近24小时内 需要审查可能和别人冲突□ 这个修改是追加还是覆盖→ 覆盖 必须审查□ 有没有在log里记录→ 没有 不算完成写在最后多Agent协作的效率提升是真实的——5个Agent、3小时、1800行代码。但效率的提升有一个前提边界设计。没有边界的多Agent协作不是协作是一群AI在同一个仓库里各写各的。速度快但质量不可控。一个Agent改了一个函数另一个Agent不知道第三个Agent引用了旧版本——代码库变成考古现场。边界不是限制效率是保护效率。就像高速公路的护栏——没有护栏你可以开300但你不敢。有了护栏你只开120但你能安全到达。写代码和改代码——这是第一条护栏。审查不能自审自批——这是第二条。任何修改必须有log——这是第三条。三条护栏保护你的项目在3小时后、3天后、3个月后还能维护。