6. 多 Agent 协作

到这一步你已经能调好一个 Agent，并且能让它从多种渠道被触发。这一章讲一个新维度——让 Agent 彼此调用。

为什么要这么做？因为很多任务天然是多角色的：写完代码后让另一个 Agent 帮 review，做完翻译后让另一个 Agent 跑 QA，分诊请求后转给真正的专家。把这些角色拆成不同的 Agent 各自调好，再让它们组合起来工作，往往比训练一个”什么都会”的 Agent 更稳定、更易维护。

基本原理

Neutree Agent Platform（NAP）支持一个 Agent 在对话里像调用工具一样调用另一个 Agent。要让一个 Workspace 能被别人调用，需要做两件事：

1. 给它一个可识别的 Slug
2. 设置可见性

打开 工作空间设置，找到 Slug 和 Visibility 字段。

Slug

Slug 是 Workspace 的唯一标识符，其他 Agent 通过它来引用。比如 qa-checker、code-reviewer、translator。

• 只允许小写字母、数字和连字符
• 留空则不可被其他 Agent 调用

Visibility

Visibility	谁能调用	调用语法
Private	不可被调用	—
User	你自己的其他 Agent	@agent/slug
Public	平台所有用户的 Agent	@agent/username/slug

在对话里调用另一个 Agent

设好 Slug 和 Visibility 后，在调用方 Agent 的对话里这样写：

写完这个方案后，让 @agent/reviewer 帮我 review 一下

调用方 Agent 会自动完成跨 Workspace 通信：把上下文传过去，等被调用方返回结果，再整合到当前对话中继续工作。

也可以用后台模式——发出去之后不等待，让被调用方在自己的 Workspace 里慢慢做，做完通过通知或者写文件的方式告诉调用方。这适合耗时较长的任务。

需要把大段资料或生成产物在 Agent 之间传递时，不要塞到 prompt 里——用 AFS（跨 Agent 文件共享），把文件写到共享目录后授权给协作方，对方在自己的容器里以同一个路径直接读到。

几种典型协作模式

不同的业务场景对应不同的协作结构。下面是三种最常见的：

1. 分诊 → 专家

入口是一个分诊 Agent，它的 Prompt 很短，唯一职责是判断”这是哪类问题”，然后转给对应的专家 Agent。

你是一个分诊助手。用户的请求会落到三类之一：
- 翻译相关 → 转给 @agent/translator
- 代码问题 → 转给 @agent/code-helper
- 其他 → 转给 @agent/general

判断后用一句话说明你的判断，然后调用对应的 agent。

好处：每个专家 Agent 可以独立调优、独立换模型、独立维护知识。新增一类问题就加一个专家，不用改其他人。

2. 流水线

任务有固定的多步骤：A 做完交给 B，B 做完交给 C。每一步都是一个 Agent。

例：翻译流水线 ——

• translator ——做翻译
• qa-checker ——检查翻译质量
• formatter ——按目标格式输出

translator 完成后调用 qa-checker，QA 通过后再调用 formatter。任何一步出问题都能定位到具体的 Agent。

3. Planner + Worker

一个 planner Agent 负责拆任务、规划步骤，然后把每一步交给对应的 worker Agent 去做，最后汇总结果。

适合任务结构事先不确定的场景——planner 看完需求才知道要拆几步、调谁。

Teamwork：任务级多 Agent 协作

上面讲的是长期固定的协作关系——A 给一个稳定的 Slug，B 长期可见、随时能调，目录也一直挂着。但很多协作其实是一次性的：

“这次我想拉两个 Agent 帮我做一份调研，做完就解散。”

“把我的私有 Agent 临时加进来用一次，不想把它永久升到 user/public 可见。”

这种场景 NAP 提供了 Teamwork（preview 阶段）。在「应用」里找到 Teamwork 入口，创建一个 team task：

1. 指定一个协调员（coordinator）Agent——它是主 Agent，sub-agent 都由它发起调用
2. 添加成员——候选列表包含所有 public / user 可见的 Agent，还包含你自己的 private Agent（如果还没配 slug 可以在这里现配）。private Agent 加进 task 后只在这个 task 里可见，不影响其他场景
3. 开始对话——平台自动给这个 task 创建一个共享目录，挂给所有成员；成员加入/离开自动挂卸；task 结束自动回收

task 详情页有一个协作时间线：每个成员的 session 一条线，每次 call_agent 在线上落一个点，显示主→次的 sub-message、次→主的 result、调用是同步还是异步。debug 多 Agent 协作时非常直观。

什么时候用 Teamwork、什么时候继续走普通 @agent：

• 长期固定的协作 → 配 Slug + Visibility，本章上半部分讲的方式
• 一次性任务、需要临时拉私有 Agent、需要共享文件——用 Teamwork

完整的设计动机和工作原理见 Teamwork 概念页。

一些实践经验

保持每个 Agent 的职责窄。 “什么都会”的 Agent 难以调优。一个 Agent 把一件事做好，比 5 个 Agent 各做半件强。

Slug 命名要稳定。 一旦其他 Agent 引用了你的 Slug，改名会导致引用方失效。命名时想清楚再定。

先用 Private/User 试，再放 Public。 Public 会把 Agent 暴露给全平台，任何用户的 Agent 都能调用你。除非你确实想做一个公共能力，否则保守一点更好。

调用关系不要套太深。 A 调 B 调 C 调 D 是可以的，但每多一层都多一倍延迟，也更难排查。三层以内是可控范围。

接下来

到这里 Agent 的”能力面”和”协作面”都有了。最后一章讲怎么把这些能力复用、共享、规模化 —— 指南 7：规模化运营。