一个人在深夜的工作台前管理一支由多个节点组成的虚拟 AI 团队

我把 Codex 当成一家公司来管,然后亲手裁掉了大半个团队

最开始,我只是想把几个并行任务分开。 一个负责找方向,一个盯产品,一个审代码,再找一个专门挑错。这样一来,我不用在一个超长对话里反复切换上下文,每个任务也能有自己的责任人。 后来有一天,我看着 Codex 侧边栏,发现里面已经有了 COO、产品负责人、技术负责人、发布验证工程师和内容秘书。再往下翻,还有一批临时研究员、接任者和组长。 我干脆给这套东西起了个名字:Aimake / 爱创,一家虚拟 AI 公司。 这是缩编之后的团队。截图是我真实使用的 Codex 项目列表,不是为了文章补画的组织图。 听起来有点像角色扮演,但真正做起来以后,它更接近一次小型的组织实验:我既是投资人,也是 CEO;AI COO 负责派单和收口;下面的人各自做产品、技术、验证、研究和内容。 实验做了一阵,我得出的第一个结论并不浪漫:启动 Agent 很容易,管理 Agent 很难。 我为什么要把任务变成“岗位” 只开一两个 Codex 任务时,管理基本不是问题。我自己记得每个窗口在干什么,也知道哪段结论值得信。 一旦任务变多,情况就变了。 每个 Agent 都能写计划、搜资料、跑测试,也都很擅长交出一份看起来很完整的报告。但报告多,并不代表事情更清楚。我开始反复遇到三个问题: 大家研究的是不是同一件事? 它说“完成了”,到底完成到哪一层? 哪些动作可以自己做,哪些必须停下来等我? 所以我没有继续靠聊天记忆维持秩序,而是给任务加上了岗位、汇报线和验收人。 每次派单尽量写成一张很短的合同: 1 2 3 4 5 6 7 目标:这次只解决什么? 交付:结束时必须留下什么? 事实源:以哪些代码、文档或运行结果为准? 完成门:满足什么才算完成? 停止门:出现什么情况立刻 Hold? 接收人:谁来复核和采用? 外部权限:哪些动作必须等我批准? 这比“认真调研一下,给我一个完整方案”有用得多。后者很容易得到一篇漂亮长文,前者才有机会得到一个能被下一位接住的结果。 然后我还是扩编过头了 这次集中冲刺里,我想同时看清产品方向、用户证据、技术架构、开源交付、安全风险和内容增长,于是短时间拉起了数十个任务。 一开始感觉非常好。屏幕上到处都在动,每隔几分钟就有新发现。不同角色从不同角度挑问题,很多盲点确实比我一个人顺序做更早暴露。 但热闹持续了一会儿,代价就出来了。 有人在重复研究同一个问题;同一款产品收到几份彼此冲突的优先级建议;上一份报告还没写完,接任它的任务已经开始;自动测试通过、真实环境可用和用户愿意复用,被几份汇报写成了差不多的“完成”。 最尴尬的是,每个 Agent 都能证明自己做了很多,却没人能证明公司应该因此改变哪个决定。 峰值时,我设置了五个临时组长,让他们吸收大约二十五个成员任务。等真正开始汇总,完整交付并被采用的只是一小部分。其余内容有的重复,有的只是阶段记录,有的结论已经被后来的验证推翻。 那一刻我才承认:我扩大的不是产能,至少不全是。很大一部分只是管理复杂度。 收工不是一句“停”,而是一场交接 我没有马上把所有任务关掉,也没有让旧岗位突然消失。 先冻结新增范围,让每个人把眼前能够安全收口的工作做完;再留下有效事实、失败记录、未知项、恢复路径和下一道门槛;接收人能够复述并独立继续之后,旧任务才归档。 ...

2026-08-13 · 1 min · Chico

多 Agent:大多数时候你并不需要

团队花三个月,搭了一套五个角色的多 Agent 编排:Planner、Researcher、Coder、Reviewer、Reporter,各司其职,消息总线串起来,架构图画得很漂亮。 上线后效果不理想——慢,贵,而且一出错就没人知道是哪一环错的。 后来有人把其中一个单 Agent 的 system prompt 重写了一遍,加了几个工具,效果追平了那套五角色编排。token 成本只有它的零头。 这种事我见过不止一次。2026 年,“上多 Agent"几乎成了一种默认的进步姿态——好像单 Agent 是入门,多 Agent 才是工程师该交的作业。我想把话说直白:大多数时候你并不需要多 Agent。 单 Agent 加上几个好用的工具,能解决的事比你以为的多得多。多 Agent 是一种有明确代价的架构选择,不是一次免费的升级。 先说清楚:什么是"多 Agent” 这个词被用得太松了,先收紧一下。 下面这些不是多 Agent,它们只是单 Agent 在干活: 一个 Agent 在循环里调用多个工具(查数据库、读文件、发请求); 一个 Agent 把一段固定的处理流程拆成几步顺序执行; 一个 Agent 调用一个"子任务工具"——把某个隔离的小任务丢给一次独立的 LLM 调用,拿回一段摘要。最后这个尤其重要,后面会专门讲。 真正的多 Agent,指的是多个各自带独立上下文、独立决策循环的 Agent,彼此之间要协调。它们要交接任务、传递状态、有时还要互相评审或辩论。LangGraph 的状态图、CrewAI 的"角色 crew"、AutoGen(现在叫 AG2)的多轮对话编排,做的都是这件事。 区别的关键在于:有没有"协调"这个动作。 单 Agent 调工具,工具是被动的、无状态的,调完就完;多 Agent 之间,每一个都是活的、有上下文的,它们要互相对齐。协调,就是多 Agent 全部代价的来源。 多 Agent 真正适用的三种场景 不是说多 Agent 没用。它有几个单 Agent 确实啃不动的场景,而且这几个场景的特征很清楚。 一,子任务能真正并行,而且彼此独立。 这是多 Agent 最硬的理由。Anthropic 公开过他们的多 Agent 研究系统:一个 lead agent 把一个宽泛的研究问题拆成若干互不相干的子查询,同时派出多个 subagent 各查各的,最后汇总。这里的"并行"是真并行——五个子查询之间没有依赖,谁先谁后无所谓,挂掉一个不影响其余四个。读密集型的、可扇出的活,是多 Agent 的主场。 ...

2026-05-16 · 2 min · Chico