单 Agent 能解决很多问题，但真实工程任务往往需要拆解、分工、校验。ACE（Agent Collaboration Engineering）是一套让多 Agent 协作可控、可复现的方法论。这篇讲它的工程动因：为什么单 Agent 不够，为什么只靠提示词不够，以及 ACE 用什么思路把协作组织起来。

单 Agent 的瓶颈：没有外部视角

很多人用 AI，是让一个 Agent 从头做到尾：自己分析、自己写代码、自己测试、自己宣布完成。这个方式在简单任务里没问题，但复杂任务里风险很高——它顺着自己的思路往下走，写完之后再让它自己检查，往往检查不出真正的问题。

它可能误判环境、重复改动、遗漏关键步骤，把没有验证的结果说成已经完成，甚至把错误包装得很像正确答案。这不是某个模型的问题，而是单 Agent 工作模式天然存在的问题。真实工程里，一个人写完代码还需要别人 code review，一个方案做完还需要别人质疑，一个系统上线前还需要测试验证。AI Agent 也是一样。如果一个 Agent 从头到尾自己做、自己验、自己宣布完成，复杂任务里的风险就会被隐藏起来。

为什么复杂任务不能只靠提示词

提示词当然重要，但它解决不了所有问题。

复杂任务的难点不是“这句话怎么问得更好”，而是：任务目标是否明确、上下文是否稳定、文件版本是否清楚、改动范围是否受控、环境是否可信、结果是否验证、经验是否沉淀、下次能不能复用。这些问题，不是一个万能提示词能解决的。

比如让 AI 帮你改代码。如果它不知道当前项目目录、不知道正式入口、不知道依赖版本、不知道哪些文件不能乱改、不知道完成后该跑什么验证，那么提示词写得再漂亮，也可能出问题。再比如做一个内容项目，如果 AI 不知道这篇内容属于哪个项目、面向谁、后续放在哪里、和其他文章是什么关系，它可能写出一篇看起来不错但无法沉淀的文章。

复杂任务需要的不只是提示词，而是工作流——更准确地说，是一套轻量的 AI 工程协作方法。

AI 放大能力，也放大混乱

AI 降低了太多事情的启动成本：不会写代码也能让 AI 帮你写，不会设计页面也能让它给方案，不会整理资料也能让它归纳，不会做 PPT 也能让它生成结构和视觉方向。这当然是巨大的变化。

但当所有事情都变得“好像可以做”之后，人很容易同时开太多坑——今天想做个人站，明天想做 AI 工具评测，后天想做自动化软件，再过两天又想研究视频工作流、知识库、开源项目、Agent 协作。能力被放大的同时，混乱也被放大。如果原来的工作方式是混乱的，AI 很可能会把这种混乱一起放大：聊天记录很多、文档很多、文件夹很多、半成品很多，但真正稳定完成的东西不多。AI 不是天然让人有序，它只是放大能力。

而且现在“复杂项目”不再是团队或公司专属。一个普通人做个个人站，会涉及内容结构、首页设计、项目页组织、文章迁移、GitHub 管理、部署和持续更新；做个 AI PPT 工作流，会涉及主题定位、受众判断、内容战略、视觉系统、导出测试和动效验收。这些事虽然都是个人项目，复杂度已经接近小型工程。AI 给了普通人做复杂项目的能力，也就自然带来了对方法论的需求。

ACE 的核心：角色与事实

ACE（Agent Collaboration Engineering）不是一个软件，也不是固定框架。它不是 Codex，不是 Claude Code，不是 WorkBuddy，也不是某个自动化平台。它更像一套工作方式：用 AI 做复杂项目时，怎么拆任务、怎么分角色、怎么让不同 Agent 协作、怎么记录工程事实、怎么控制风险、怎么做验收、怎么把有效经验沉淀下来。它解决的是 AI 参与真实项目时的组织问题。

它的核心思路是：不同 Agent 应该有不同角色，角色是动态的，任务事实是稳定的。

有的 Agent 负责架构，有的负责施工，有的负责审查，有的负责测试，有的负责总结沉淀。ACE 不把某个模型固定绑定到某个角色——这和“一个 Agent 从头做到尾”是根本区别。单个 AI 工具再强，如果没有组织方式，也很容易在复杂任务里跑偏。

在 AI 工程协作里，事实层尤其重要。当前项目目录是什么、正式入口是什么、用哪个运行时、哪些文件被改过、哪些验证已经跑过——这些都不能只靠聊天记录。ACE 重视两类事实：

  • 环境事实源：每个项目都应尽量明确工作目录、操作系统、正式入口、解释器或运行时路径、依赖锁定文件、配置文件、关键命令和验收方式。原则是“找不到，不等于没安装；报错，不等于应该重装；当前 shell 找不到，不代表系统里不存在”。这样可以避免 AI 无边界搜索，也避免一遇到报错就重装、重建、重配环境。
  • 版本事实层：ACE 采用 Jujutsu + Git 的双层路线。Git 保留为兼容、交换、commit、diff、CI、审计和协作账本的事实层；Jujutsu 更适合本地变更整理、撤销和 workspace 管理。这套组合的核心价值是让 AI 的改动有迹可循——多 Agent 协作时，大家应该围绕真实 diff、commit 和变更事实讨论，而不是围绕聊天记录。

任务分层与最少充分验收

不是所有任务都需要复杂流程。有些任务直接完成就行，不应该为了工程化而工程化。ACE 根据任务复杂度和风险决定处理方式：简单任务走轻量路径；中等任务拆分步骤；高风险任务先做蓝图、再施工、再验收；多 Agent 任务则明确角色、边界和交接方式。背后的原则很简单：流程为任务服务，不为了流程而流程。

验收同样如此。很多 AI 工程任务失败，不是因为没有做，而是因为没有真正验收；但另一个极端也很常见——为了显得严谨，每次都搞一套巨大验收，最后流程本身变成负担。ACE 采用最少充分验收：只验证本次改动直接影响的关键链路。小范围文案或样式改动不做全量回归；改配置就验证配置是否被正确读取；改入口就验证正式入口能不能跑通；改生产链路才需要更完整的回归和证据包。最少充分验收不是偷懒，而是把验证做到刚好够用。

轻量优先：先做事，后沉淀

说到工程方法，很多人会想到很重的流程：需求评审、架构设计、开发规范、测试报告、项目管理系统、多人协作平台。这些对大团队可能有必要，但对普通人太重了。普通人真正需要的不是复杂系统，而是轻量方法：这个任务要不要拆、哪些先做哪些先不做、AI 这次只负责什么、哪些文件可以改哪些不能碰、当前可信环境是什么、做完后最低限度验证什么、这次经验有没有必要沉淀。

这能避开两种极端。一种是完全无流程：想到什么做什么，AI 改到哪里算哪里，越做越乱。另一种是过度工程化：还没开始做事就先搭系统、写规范、建模板、做流程，最后真正产出反而很少。我更认可中间路线：先做事，后沉淀。轻量优先，复用优先。流程只服务于真实推进。 这也是 ACE 的核心精神。

Skill 沉淀遵循同样原则：只有真正可复用、高风险、反复失败、能提高效率的能力，才值得沉淀成 Skill。过度文档化会把知识库变成负担——整理系统的时间变多，真正做事的时间变少。先做事，后沉淀。

ACE 目前不是成熟产品，也不是万能框架。它更准确的状态是：一套正在真实项目中持续进化的个人 AI 工程协作方法论。它不追求完整而完整，而是越来越明确地——先做事，后沉淀，轻量优先，复用优先。