让 AI 自己组队：Raven 到底怎样把任务做完？

让 AI 自己组队：Raven 到底怎样把任务做完？

你让 AI 做一个小游戏。它写了一段代码，你又去找另一个 AI 画素材，再把报错复制回去。忙了一圈，你成了几个 AI 之间的“人工传话员”。

Raven 想解决的，就是这类协作问题：接住目标，拆出任务，把工作交给合适的 Agent，再把结果收回来。理解它，先看清任务怎样流转，比记住一串工具名更有用。

CC Switch 管连接，Raven 组织任务

如果你刚接触这些工具，可以先分清两个问题。

“我想给编程助手换一家模型服务，管理工具连接、提示词和 Skills。”这是 CC Switch 的典型用途。它把分散的配置放在一个桌面入口里管理。

“我要做一个东西，哪些步骤能同时进行，谁先做、谁后做，结果怎样合起来？”这是 Raven 的多 Agent 编排重点。

这是一种帮助入门的比较。两个工具解决的问题不同，不能只用“谁全面取代谁”来理解，也不用为了学习 Raven 先把所有工具装一遍。

用一个小游戏，看懂分工与依赖

假设目标是做一个“躲陨石”小游戏。我们可以把工作拆成：先定玩法，再分别准备飞船和陨石素材、编写移动与碰撞逻辑，随后测试，最后整理交付文件。

设计和代码可以并行，测试要等两边准备好。 箭头表示的就是这种前置依赖，而不是装饰线。把这些任务和依赖画成不绕回原点的图，就是 DAG，中文叫“有向无环图”。

上图来自本期动画，是帮助理解协作的示意，百分比也为演示设计；它不是 Raven 在本机实际开发这个游戏的记录。这套分工也不是每个任务必须照搬的固定流程。

Raven 的 Host 可以理解为协调入口：分派工作、跟踪进展，再汇总各项结果。它提供 Research、Design、Code、Oncall 等专业角色；外部 Agent 也要先完成安装、启用和认证。仅在对话里写一个产品名，并不会自动获得它的能力。

Agent、Sub-agent、Harness，各自是什么？

Agent 可以把它理解为一个能围绕目标使用工具、推进任务的工作者。Sub-agent 是被委派去完成某个明确子任务的 Agent。重点在任务边界：让它做什么、可以改什么、需要交回什么证据。

模型则更像思考引擎。要让它实际做事，还需要工具、文件环境、记忆、规划方法和执行规则。围绕模型组织起来的这套工作系统，常被称为 Harness。

因此，换一套 Harness，可能改变 AI 如何找资料、选工具和检查结果；这与重新训练模型的权重是不同的事情。多个 Agent 也不会因为“组队”就天然配合得好，仍需要清楚的任务、文件边界和验收。

做顺一次，再把流程留下来

如果某类任务经常重复，例如“收集资料、整理要点、检查事实、生成报告”，可以考虑把经过检查的流程保存成 Playbook。

它更像一份可重复使用的作业流程。下次换输入材料，沿用已经梳理好的步骤；实际执行仍依赖可用的 Agent、工具和结果检查。保存了 Playbook，不等于任务已运行，每次输出仍需逐项验收。

第一次尝试，先写清四件事

先挑一件范围小、结果容易检查的任务。下面这段可以作为任务说明的起点，再按你的实际目录和工具修改：

请在指定的空白项目目录里做一个最小版“躲陨石”网页小游戏。先列出任务和依赖，再开始执行。只修改该目录，不覆盖其他项目。交付可运行文件、启动说明、实际完成的检查和仍未解决的问题。涉及付费服务、外部发布或需要我提供权限时先停下说明。完成后按“能启动、能移动、能计分、能重新开始”逐项验收；没有实际运行的检查请明确写出。

这里最有用的是四件事：工作范围、交付物、可用权限、验收方法。 它们能减少“看上去做完了，实际接不起来”的情况。

看演示或评测，也用同样的眼光：计划拆得是否合理，文件能否打开，功能是否跑通，耗时和成本是否合适。这些是不同的问题，不能用一张漂亮的任务图代替最终交付。

先让一个小任务顺利走完，再增加角色和步骤。你会更容易发现，真正节省时间的，是哪一段协作。

参考：CC Switch 官方仓库；EverMind Raven 官方文档《Working with Sub-agents》《Agent Integrations》《Architecture》《Playbooks》。

零一道 · 谯洪敏