之前我用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都在自己的上下文窗口里局部优化，全局一致性被破坏。
最后是CEO（Orchestrator）出面：先读完所有调用点，确认改动范围，然后一次性修正均线函数、更新所有调用方、跑完整测试。用时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场景下，它是唯一的质量底线。
真实案例：公众号文章发布流程。每篇文章写完后的审查步骤：
2. 格式修正——有没有微信不支持的编号列表（变黑点）
3. 代码块渲染——<div> 灰底白字格式是否正确闭合
4. AI痕迹清除——有没有"本文由辅助撰写"、"让我们"等字样
这些审查如果交给写文章的Agent自己做，等于让考生批改自己的试卷。
三、为什么"写代码"和"改代码"需要不同权限
这是整个边界设计的核心问题。
3.1 上下文窗口不对称
一个Worker Agent在执行任务时，上下文窗口里装的是"当前任务相关的代码"。它不知道：
• 改动会影响哪些下游系统
• 3天前别人为什么这样写
• 这段代码是不是在修另一个bug时引入的workaround
让一个看不到全局的Agent去改全局代码，就像让一个只看了引擎盖下的修理工去调变速箱——他能拧螺丝，但不知道这辆车为什么抖。
3.2 修改的"蝴蝶效应"
真实案例。在89份PDF批量摄入到LLM Wiki的过程中，有一次我发现[[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轴改成自适应范围。
正确做法：
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就完事。但它不会考虑：
• 加了这个参数会不会影响脚本的其他部分？
• 其他依赖（ninja-build、pkg-config）是不是也有更好的apt替代方案？
实际的正确做法：
2. 审查层（人工+Agent）评估：这不是pip的问题，是Ubuntu 24.04的策略变更
3. 决策：不用 --break-system-packages，改用 apt install python3-meson python3-ninja
4. 更新所有依赖安装策略（不只是这一个包）
5. 更新方案文档，记录决策原因
6. 生成 check_deps.sh 自动检测脚本，避免下次踩同一个坑
如果让执行层Agent自己"修一下"，它不会走到第3步——它只看到pip报错，看不到系统包管理器的替代方案。
六、真实案例三：Ingest Pipeline的"改知识"边界
在上面提到的89份PDF→LLM Wiki的Ingest Pipeline中，有一个比代码更敏感的"修改"场景：修改已有的知识页面。
当新的PDF（比如《裸烧及非裸烧升级 使用手册》）被摄入时，Agent需要判断：
• 新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觉得对不对"）
铁律三：任何修改必须有log
理由：没有记录的修改 = 不存在。三个月后没人知道为什么改的。
操作方式：
• 知识修改 → log.md 追加（不可变日志，只追加不修改）
• 配置修改 → 变更记录（改了什么、为什么、影响范围）
八、什么时候可以"放宽"边界
不是说所有场景都必须走严格的3层审查。有些场景下，边界可以适度放宽：
可以放宽的场景：
✅ Agent自己创建的新文件（还没有被其他模块依赖）
✅ 格式修改（不影响逻辑，如代码格式化）
✅ 单Agent独占的项目（没有多人协作的冲突风险）
绝不能放宽的场景：
❌ 已经部署到生产环境的代码
❌ 其他Agent也在编辑的同一个文件
❌ 知识库中的已有页面
❌ 配置文件（改错一个参数影响全局）
九、对比：业内其他方案的边界设计
来看看业界主流方案是怎么处理这个问题的：
| 方案 | 边界设计 | 优点 | 问题 |
|---|---|---|---|
| Claude Code (Anthropic) | 人工审批所有文件写入 | 安全可控 | 人工成为瓶颈 |
| Codex CLI (OpenAI) | 默认审批，可配置always approve | 灵活 | 配置失误后果严重 |
| Cursor Agent | Agent直接写文件，人工可回滚 | 速度快 | 回滚成本高 |
| 本文方案 | 3层边界：规划→执行→审查 | 平衡效率和安全 | 需要Agent间通信机制 |
我的方案不是最自动化的——但它是唯一一个在3小时后还能维护的方案。
十、给你的实操建议
如果你正在搭建自己的多Agent协作系统，以下是可以直接拿去用的规则：
建项目时的初始设置：
2. Worker Agent 只开放 write_file（创建新文件），禁止 patch（修改已有文件）
3. 任何代码修改走 Mini-PR 流程：Worker提方案 → Orchestrator审查 → 确认后执行
4. 所有操作记录到 log.md：时间、操作者、改动内容、原因
5. 安全扫描和格式检查设为自动化规则，不依赖Agent主观判断
运行中的检查清单：
□ 这个文件被几个模块引用？→ 超过0个 = 需要审查
□ 上次修改是什么时候？→ 最近24小时内 = 需要审查（可能和别人冲突）
□ 这个修改是"追加"还是"覆盖"？→ 覆盖 = 必须审查
□ 有没有在log里记录？→ 没有 = 不算完成
写在最后
多Agent协作的效率提升是真实的——5个Agent、3小时、1800行代码。
但效率的提升有一个前提：边界设计。
没有边界的多Agent协作，不是协作，是"一群AI在同一个仓库里各写各的"。速度快但质量不可控。一个Agent改了一个函数，另一个Agent不知道，第三个Agent引用了旧版本——代码库变成考古现场。
边界不是限制效率，是保护效率。
就像高速公路的护栏——没有护栏你可以开300，但你不敢。有了护栏你只开120，但你能安全到达。
写代码和改代码——这是第一条护栏。审查不能自审自批——这是第二条。任何修改必须有log——这是第三条。
三条护栏，保护你的项目在3小时后、3天后、3个月后还能维护。
)
