封面专题
越想让它听话，为什么越难交付？
一位游戏开发者的失败，让「多写几条规则」这条捷径失效了。接下来要做的，是重新安排信息、判断与检查各自的位置。
从 800 行规则开始，看见真正的故障
先认识这位开发者在做什么。刘俊毅的案例是一款 Cocos Creator 微信小游戏：客户端、服务端、协议与需求分处四个仓库，不同角色要交接工作。他希望 AI 按设计实施，于是不断补充 Skill 和约束，从五百多行涨到八百多行，还列出必须遵守的规则。结果却是：步骤仍会跳过，到了下一阶段，前面的要求又可能失踪。13
这不是一个干净的「长提示词对短提示词」实验，文章也不能证明 800 行是某种失效阈值。更值得看的，是作者记录的一次具体偏差：装饰摆放系统限定一次批量收回最多 20 个物品，任务拆解却写成了收回全部，执行者再忠实地把「全部」做出来。每个人都能解释自己做了什么，最终产品仍然错了。
真正丢失的是约束的来历。 如果实现者只能看到上一棒的摘要，它很难分辨「全部」究竟是产品决定，还是某次转述漏掉了上限。再加一句「严格遵守需求」，并不会自动把丢失的信息找回来。
01 / 约束在哪里丢了
20 → 全部：一次交接里的语义漂移
- 需求最多 20 个
用户设定了上限
- 任务摘要收回全部
转述时，上限丢了
- 实现结果忠实地做错
代码符合摘要，却违反需求
设计核对原始边界 → 任务引用设计 → 实现再读设计
根据作者记录的批量收回案例整理；不是一次模型能力基准测试。[13]
作者后来搭建了分阶段的 x-flow：保留专门角色，把设计、任务和实现连接到可核对的产物，重要节点暂停给人检查。这里最有启发性的变化，不是阶段数量更多，而是每一步有了可以回头找的依据。设计检查需求里的边界，任务引用设计，实现时再读设计，能让那个「20」在中途被发现，而不是等到用户遇到错误。
有些规则应该被执行，有些知识应该等用到再读
这个案例还记录了一类常见故障：某种跨分包的静态导入在编辑器里没出事，真机首次加载却崩了。把教训继续塞进提示词，等于每次都期待模型记住；写成检查脚本，则能在提交前确定地指出哪里违反了约束。13
能可靠判定的条件，应该尽量让程序判定。 这并不要求所有产品判断都变成代码。设计好不好看、一个功能是否值得做，仍然需要上下文与取舍；文件是否存在、协议版本是否一致、导入路径是否合法，则不必反复交给语言模型猜。
02 / 规则的去处
不必每次都读完一整本手册
- 始终生效最小约束
- 目标、权限、不能越过的边界
- 遇到任务再读Skill 与参考资料
- 该阶段的步骤、领域知识、历史经验
- 执行时检查工具与脚本
- 版本、路径、前置条件、固定格式
- 交付时判断人和验收样例
- 真实体验、产品取舍、关键例外
图里的分法是本期据案例整理的工作方法。它同时包含两种减法：一是把随时必须遵守的约束缩短，让它们更醒目；二是把只在某个阶段有用的资料移到按需读取的位置。知识没有被丢掉，只是不用在每轮对话里重新搬家。
这也解释了为什么「有记忆」不等于「有可靠经验」。一条旧结论必须附着在适用条件、日期与证据上；代码事实最好从当前代码读取。常用但过时的建议可能很危险，罕用的发布限制却未必该删。清理规则时，要看它是否仍然正确、能否被更可靠的机制接管，而不是只看出现频率。
子 Agent 让工作并行，也让理解重新开始
本周另一篇关键阅读来自 Anthropic。它建议一些企业系统把高度关联的子 Agent 收回主循环，通过 Skills 与工具承载专门知识；理由之一是，多次交接会带来上下文损耗与额外等待。但它也明确保留了使用子 Agent 的场景，包括上下文隔离、独立并行和相互冲突的工具环境。16 官方原文
想象一个客服任务：客户既问订单，也问何时到货。若两个专员一直围绕同一订单往返，它们分工所省下的复杂度，可能抵不过共享信息、同步状态与汇总答案的成本。一个持有完整对话的 Agent，配上两个查询工具，也许更合适。组织里有两个部门，并不意味着运行时必须有两个脑袋。
反过来，审查者不想沿着实现者的自我解释继续走，或者两项调查能各自完成再合并，独立上下文就可能有价值。单循环也可以并行调用工具；需要并行，并不是增加子 Agent 的充分理由。
03 / 上下文与边界
让需要一起理解的信息，待在一起
共享同一段理解
同一个目标、同一批数据，减少重复转述。
独立任务再分出去
每项有明确输入与产物；合并时仍需核查。
我更愿意用「信息需要待在一起吗」来判断边界。若后一步总要反复追问前一步的推理，先尝试合并；若任务有独立输入、明确产物，而且主 Agent 能检查结果，再考虑分出去。判断依据是任务之间的联系，而不是给团队画出一张看起来完整的组织图。
为什么另一位架构师仍然鼓励多开几个 Agent？
InfoQ 这周转述的 Carlos Kelkboom 访谈，提供了一个很好的反例：架构与代码骨架由人掌握，再让多个 Agent 探索实现；对自己已经看不懂的代码，宁愿在隔离分支重来，也不继续叠补丁。06
这与减少交接并不矛盾。几个 Agent 各自探索同一个问题，和几个 Agent 接力改写同一份需求，是两种结构。 前者增加备选方案，代价是重复劳动与比较成本；后者分摊步骤，代价是中途信息可能变薄。它们都不能因为「开得更多」而自动变好。
腾讯案例本身也没有删掉所有专门角色。多仓库、协议边界和人工协调是它的现实条件，分阶段的流程有存在理由。把这篇经验简单概括为「不要用多 Agent」，反而会读反原文。
真正可复用的做法，是让每个额外角色说明自己的收益：它隔离了什么干扰，发现了什么独立错误，或者节省了哪段可测的等待？如果答案只是「这样更像一个团队」，那层结构还没有证明自己的必要性。
减法有没有做对，要看原来会的事还会不会
合并之后跑得快，只完成了一半验证。Anthropic 的示例里，合并客服角色降低了延迟，却漏掉原本能给出的送达日期；问题只在重复运行中暴露出来。16
所以，值得保留的不是一张架构前后对照图，而是一小组真实任务：输入是什么、必须交付哪些结果、哪些条件不能越过、最终产物在哪里。每次只改一个结构，再检查哪些任务从失败变成功，哪些从成功变失败，而不只看一个平均分。
04 / 改动后的检查
平均分以外，看看哪一题退步了
新结构帮到了什么？
保存输入、结果与可重复的检查。
原来的哪项能力丢了？
例如订单查到了，却漏了送达日期。
同一题多跑几次
偶发漏项也算回归，不能只挑最好一次。
示意检查方法，不是本刊跑出的成绩。同时记录完成率、等待、成本与返工。[16]
上期补记的腾讯研发流程文章，本周又落入正式收藏区间。它把注意力从 AI 写代码延伸到需求、协作与交付，刚好接上这个问题：局部生成更快以后，瓶颈可能转移到等待、核查和返工。01
本期的减法因此有一个很实际的目标：减少那些没有改善交付的指令、角色与重复说明，让留下的检查真正保护任务。删到多少行、剩下几个 Agent，都不是终点。
