Multica：把 AI Agent 真正接入团队协作流

说说我当时是怎么找到 Multica，因为当时 openclaw 爆火的时候，我在深度使用后，就想说通过一个 mission control 来给所有的 Agent 指派任务去帮我开发，监控任务进度。然后自己也实现了一个简单的 mission control，直到我看到了Multica，这不就是我想要的工具吗？让 AI Agent 真正成为团队的一员，而不是一个外挂的聊天机器人。

这篇文章不是功能说明书，是我深度使用 Multica 后的理解整理，包括它怎么运转的、各个名词到底什么意思，以及如果你要用，有哪些坑和最佳实践。我最近一直在关注 Multica，Openclaw中每天都会拉取他的release，目前该项目还处在高速更新中，部分内容可能在新版本中不适用，请注意。

Github地址：Multica

一、Multica 到底在做什么

传统的项目管理工具，核心逻辑是"人分配给人"。你创建一个 issue，分配给同事，同事看到后动手解决。

Multica 的核心逻辑是"人分配给 Agent，Agent 在自己的机器上自动执行"。

这带来了一个根本性的区别：你的代码、API 密钥、运行环境，全部留在本地，Multica 的服务器只负责协调——它不碰你的代码，也不碰你的密钥。

三个核心组件

Multica 的架构由三个部分组成，理解它们就理解了一切：

1. Multica Server（服务器）

这是 Multica 的大脑，托管在云端或者你自己部署。它管理着 workspace、issue 列表、成员权限、评论线程、任务队列。它也是一个 WebSocket 枢纽，负责把你和同事的操作实时同步给彼此。

但它不执行任何 Agent 任务。

2. Daemon（守护进程）

这是运行在你自己机器上的一个进程，属于 Multica CLI 的一部分。启动时，它会检测你本地安装了哪些 AI 编程工具（Claude Code、Codex、Cursor、Copilot 等等），向服务器注册，然后每 3 秒轮询一次有没有新任务，每 15 秒发送一次心跳。

Daemon 是连接你和 Multica Server 的桥梁。

3. AI Coding Tool（AI 编程工具）

这是真正干活的那个。目前支持 11 个工具：Claude Code、Codex、Cursor、Copilot、Gemini、Hermes、Kimi、Kiro CLI、OpenCode、OpenClaw、Pi。

Daemon 拿到任务后，会在本地创建一个隔离的工作目录，然后调用对应的 AI 工具来执行。代码写在你的机器上，测试在你的机器上跑，API 调用用的是你的密钥。

所以整个流程是这样的：你在 Web 界面上 assign 一个 issue → Server 创建任务 → Daemon 3 秒内 pickup → 本地 AI 工具开始工作 → 结果回传到 Server → 你和队友实时看到更新。

你的代码。你的密钥。你的 CPU。

这点很重要。不管你用 Cloud 版还是 Self-host 版，这个隐私模型都是一样的。

二、名词概念：每个词到底是什么意思

Multica 引入了不少术语，有些在其他工具里也有，但含义可能不同。一个一个说清楚。

Workspace（工作空间）

相当于一个团队的容器。所有成员、项目、issue、agent 都在一个 workspace 里。一个人可以加入多个 workspace，但 workspace 之间数据隔离。

Issue（工单/问题）

工作单元，和传统项目管理工具里的 ticket 类似。有标题、描述、状态（todo / in_progress / done / backlog 等）、优先级、指派人。但和传统工具的区别在于：issue 可以被 assign 给一个 Agent，Agent 会自动开始工作。

Issue 和 Task 是两回事。一个 issue 可以被反复 assign、@mention、手动 rerun，每次都会产生一个新的 task。

Project（项目）

相关 issue 的集合。比 workspace 小，比单个 issue 大。一个 launch、一次迁移、一个多部分的功能开发，都适合建一个 project。每个 project 有名字、图标、描述、负责人（可以是人类或 Agent）、状态、优先级，还有一个自动计算的进度条——根据下面 linked issues 的完成比例来算。

删除 project 不会删除里面的 issue，只是解除关联。这个设计很对，项目的框架变了，里面的工作很少真的变成垃圾。

Agent（智能体）

这可能是 Multica 最核心的概念。Agent 是 workspace 的一等成员——可以被 assign issue、可以发评论、可以被 @mention、可以成为 project lead。

但它和人类成员有几个关键区别：

自动启动：被 assign 或 @mention 后，Multica 立刻 dispatch 任务，不需要像等人回复那样等待
不收通知：它不会出现在你的 inbox 里，也不会收到 @all 的消息。它不是"读消息的人"，而是"被触发执行的工作单元"
绑定一个 AI 工具：每个 Agent 都和一个 runtime 绑定（runtime = daemon × 一个 AI 工具）。如果工具离线，Agent 就无法工作
可以被归档：不用的 Agent 可以 archive，随时恢复

Agent 有两种可见性：

Workspace：所有成员都可以 assign 它
Private：只有 owner、admin 或创建者可以 assign。注意，其他成员还是能看到这个 Agent 的名字和描述，只是看不到配置详情（环境变量、MCP 配置等敏感字段会被遮盖）

Daemon（守护进程）

前面讲过，运行在你本地机器上的进程。它负责：

检测本地安装了哪些 AI 工具
向 Server 注册 runtime
每 3 秒轮询任务
每 15 秒发送心跳
接收任务后在本地创建隔离工作目录
调用 AI 工具执行
把结果回传给 Server

一个 daemon 如果同时安装了 Claude Code 和 Codex，又加入了两个 workspace，Multica 会注册 4 个独立的 runtime（2 workspace × 2 工具）。

Runtime（运行时）

Daemon 和一个 AI 工具的配对。目前的版本只支持本地 runtime——也就是说，你必须有一台开着 daemon 的机器，Agent 才能工作。Cloud runtime（不需要自己跑机器）还在 waitlist 阶段。

Task（任务）

Agent 每一次执行都会产生一个 task。它有明确的状态机：

Queued：刚创建，等待 daemon pickup
Dispatched：daemon 已认领，正在启动 AI 工具
Running：AI 工具正在工作
Completed：成功完成，结果已写回
Failed：出错或超时，可能自动重试
Cancelled：用户取消

超时规则：

Dispatched 后 5 分钟还没启动 → timeout
Running 超过 2.5 小时 → timeout

失败分两种：

Retryable（自动重试）：runtime_offline、runtime_recovery、timeout。最多重试 1 次（原任务 + 1 次重试）
Non-retryable（不重试）：agent_error（AI 工具本身报错，比如 API 错误、配额用完）

注意：只有 issue-triggered 和 chat-triggered 的任务会自动重试，Autopilot 的任务不会自动重试——因为它本来就有自己的调度周期。

Squad（小队）

一组 Agent（和可选的人类成员），由一个 Leader Agent 带领。把 issue assign 给 squad 时，Leader 会读 issue，然后决定哪个成员最适合做这件事，通过 @mention 把任务派出去。

Squad 的价值在于路由。你把专家组装成一个小队，以后只需要按 squad 分配，不用记每个人（每个 Agent）擅长什么。更关键的是，Squad 能让一个 issue 在多个 Agent 之间自动流转——Leader 充当总调度，成员按阶段接力。

Leader 在每次运行时，系统会给它追加三段提示：

Squad Operating Protocol（硬编码规则）：读 issue → 用 @mention 委派 → 每次记录评估 → 派发后停止
Squad Roster：成员列表，包含精确的 mention markdown（不能用普通的 @name）
Squad Instructions：你自己写的自定义路由规则

什么时候用 squad，什么时候用单个 Agent？

有多个专家，事先不知道谁适合这个 issue → squad
工作范围很明确，知道该谁做 → 单个 Agent
想要一个稳定的 assignee（squad），实际执行者按需变化 → squad
想让 issue 按流水线自动流转（产品 → 开发 → QA）→ squad，且必须在 Instructions 里写清楚流转规则

Skill（技能）

Agent 的知识包。一个 SKILL.md 加上可选的辅助文件（脚本、配置、模板），告诉 Agent"遇到这类任务时，按这个思路来"。

Multica 采用 Anthropic 的 Agent Skills 开放标准，所以兼容的 skill 可以从 Anthropic 官方仓库、ClawHub、skills.sh 直接导入。

有两种来源：

Workspace skill：存在 Multica 云端，attach 到 Agent 后，执行时同步到本地
Local skill：存在你机器的默认路径里（比如 Claude Code 是 ~/.claude/skills/），手动选择导入到 workspace

Skill 和 MCP 的区别：

Skill = 结构化知识包（静态内容 + 指令）。Agent 读 skill 来学习"遇到 X 问题怎么思考"
MCP = 工具通道。Agent 用 MCP 连接外部服务（数据库、文件系统、第三方 API）并调用它们

二者互补。目前 MCP 支持主要是 Claude Code 在真正消费。

安全提醒：从 GitHub 或 ClawHub 导入的 skill 可能包含脚本和可执行内容。Multica 不签名、不审计、不沙箱——skill 内容直接交给 AI 工具处理。2026 年 2 月 ClawHavoc 事件就是个教训：恶意 skill 窃取了用户的 API 密钥。只从可信来源导入，敏感项目只用自己写的 local skill。

Autopilot（自动巡航）

让 Agent 按时间表自动工作的机制。配置一个 cron 表达式和时区，Multica 就会在指定时间自动 dispatch 任务，不需要你手动触发。

两种执行模式：

Create issue 模式（推荐）：每次触发先创建一个 issue，再按正常流程 assign 给 Agent。所有工作都在 issue board 上可见
Run-only 模式：直接 enqueue 任务，不创建 issue。执行记录只能在 Autopilot 的 run history 里看到

触发方式：

定时触发：标准 5 字段 cron（分钟小时日月星期），最小粒度 1 分钟
手动触发：UI 点"Run now"或 CLI multica autopilot trigger <id>
Webhook 触发：生成唯一 URL，POST JSON 即可触发。URL 就是凭证，泄露了就要 rotate

Autopilot 失败不会自动重试，也不会发 inbox 通知。这是设计如此——它本来就会按周期再次触发，自动重试会叠加上去造成重复执行。如果某个 Autopilot 很重要，自己设计监控机制，比如让 Agent 成功后在 issue 下 post 一个 comment。

Chat（聊天）

你和 Agent 的一对一对话，完全在 issue 体系之外。Agent 看不到任何 issue，也改不了任何 issue，整个对话完全私密（workspace 里其他人，包括 admin，都看不到）。

适合讨论不隶属于任何 issue 的话题、头脑风暴、或者你不想让其他人看到的讨论。

每次消息触发一个 task，所以回复可能需要几秒。多轮对话通过 provider session resumption 保持上下文——Agent 建立 session 后，session ID 被保存，下次消息传回去继续对话。

Inbox（收件箱）

你的通知中心。Agent 不会收到 inbox 通知，但人类成员会。比如有人 @ 了你、issue 状态变化、评论回复等。

三、四种让 Agent 工作的方式

Multica 有 4 种触发 Agent 的协作模式：

方式	典型场景
Assign an issue	最常用。把 issue assign 给 Agent，它自动开始
@mention in comment	"帮我看看这个"——不改 assignee 和状态，只是抛出一个评论任务
Direct chat	独立对话，不关联任何 issue——问问题、起草 issue
Autopilot（定时）	固定指令——"每周一早上的 standup summary"

我的建议是：大部分工作用 assign，需要快速反馈但不改变 ownership 时用 @mention，纯讨论或敏感话题用 chat，周期性重复工作用 autopilot。

四、Squad 流水线：issue 怎么在 Agent 之间流转

这是很多人拿到 Multica 后最困惑的问题：我定义了多个 Agent，比如一个主 Agent、一个产品经理 Agent、一个开发 Agent、一个 QA Agent。现在有一个开发任务，我想让它先走产品分析，再走开发实现，最后走测试验收。创建 issue 的时候我该 assign 给谁？

答案是：assign 给 Squad，让 Leader 做总调度。

为什么不能 assign 给主 Agent 再让它"转交"

直觉上你会觉得——先 assign 给主 Agent，它干完自己的部分，再把 issue 分配给开发 Agent，开发完成后再给 QA Agent。但 Multica 里，Agent 不能直接修改 issue 的 assignee。它能发评论、能 @mention 别人、能开新 issue，但没有"转交任务"这个操作。

如果你把 issue assign 给单个 Agent，它运行一次任务就结束了。就算它在评论里 @mention 了开发 Agent，开发 Agent 虽然会被触发，但开发完成后谁来通知 QA？没人自动协调。流程会断在半路。

Squad 的存在就是解决这个：Leader 不是执行者，是常驻的协调器。每次成员动一下，它就被唤醒，判断下一步该谁上。

搭建流水线的具体步骤

第一步：创建 Squad

比如叫"产品交付团队"。

Leader：你的主 Agent。它的唯一职责是读 issue、判断当前该进哪个阶段、然后 @mention 对应的子 Agent。
成员：产品经理 Agent、开发 Agent、QA Agent，都加进去。每个成员写一句角色描述，比如"负责需求分析和 PRD 梳理"、"负责代码实现"、"负责测试验收"。

第二步：写 Squad Instructions

这是最关键的一步。Instructions 会追加到 Leader 的 prompt 里，告诉它怎么路由。示例：

我们是产品开发团队。当一个 issue 被分配给我们时，按以下流程处理：

1. 初始阶段：先评估 issue，如果需要需求分析或需求不明确，@mention 产品经理 Agent
2. 开发阶段：需求确认后，@mention 开发 Agent 进行实现
3. 测试阶段：开发完成后，@mention QA Agent 进行测试验收

每次委派时，在评论中简要说明当前处于哪个阶段、为什么派给这个成员。
等待成员完成并评论后，评估下一步该进入哪个阶段。

你可以写得更细："如果 issue 描述里包含'设计稿'、'UI'等关键词，先派给产品经理"、"如果评论里出现'已实现'、'代码已提交'，进入测试阶段，派给 QA"。Leader 的判断质量完全取决于这些指令的清晰度。

第三步：创建 issue 时 assign 给 Squad

在 assignee picker 里选中这个 Squad。然后整个流程自动开始。

完整的流转过程

你创建 issue，assign 给 Squad
Leader 被触发，读 issue + Squad Instructions + 成员列表
Leader 判断：这是新需求，先理顺。它发一条评论，用精确的 mention markdown @mention 产品经理 Agent（注意：不能用普通的 @name，必须用 roster 里的 [@Name](mention://agent/...) 格式）
产品经理 Agent 被触发，读 issue 和 Leader 的委派评论，开始工作
产品经理完成后发评论（比如"需求已梳理，建议实现 XXX"），评论里没有 @mention 任何人
Leader 被重新触发——文档明确说了：squad member 发了 progress update 且没有 @mention 任何人时，Leader 会 re-evaluate
Leader 判断：需求阶段结束，该开发了。发评论 @mention 开发 Agent
开发 Agent 被触发，开始编码
开发完成后发评论，Leader 再次被触发，@mention QA Agent
QA 完成后发评论，Leader 触发，可以在评论里说明"验收通过"或把 issue 状态推到 done

整个过程中，issue 的 assignee 始终是 Squad，不需要人工改。流转的动力来自 Leader 的 @mention 和成员的完成评论。

不用 Squad 的替代方案

如果团队比较简单，也可以不用 Squad，而是拆成多个 issue：

Issue 1：需求梳理，assign 给产品经理 Agent
Issue 2：功能开发，assign 给开发 Agent
Issue 3：测试验收，assign 给 QA Agent

缺点是失去了"一个 issue 贯穿全流程"的追踪性，好处是架构简单、每个阶段责任清晰。适合流水线不固定、每次需要人工判断下一步的场景。

几个关键细节

Leader 不干活，只调度。 文档写得很清楚：Leader 的职责是路由，不是实现。即使你的主 Agent 本身有能力做需求分析，当了 Leader 后它的设计意图也是委派出去。如果你的主 Agent 本身也要干活，把它拆成两个 Agent：一个纯 Leader 做协调，一个执行 Agent 做实际工作。

成员的完成评论里不要 @mention 任何人。 如果开发 Agent 完成后在评论里直接 @mention 了 QA Agent，Leader 不会被重新触发（因为已有显式路由，Leader 会"让开"）。想 Leader 继续协调，就让它发一个干净的评论，Leader 自动接管下一步。

Squad 可以嵌套使用吗？ 不行。一个 Squad 的成员可以是 Agent 或人类，但不能再放另一个 Squad。如果你的团队很大，考虑按模块拆成多个 Squad（比如"前端 Squad"、"后端 Squad"），而不是在一个 Squad 里塞太多成员。

五、最佳实践

1. 从单个 Agent 开始，别急着上 Squad

Squad 的路由能力很诱人，但它增加了复杂度。Leader Agent 的决策质量取决于你给它的 instruction 和 roster 描述。一开始先用单个 Agent 跑通流程，等真的有了多个 specialist Agent、确实出现"不知道派给谁"的场景时，再组装 Squad。

2. 给 Agent 写清楚的 system prompt

Agent 的 system prompt 是它理解任务的窗口。不要写"你是一个有帮助的助手"这种废话。写具体：

这个 Agent 负责什么类型的任务
它应该使用什么技术栈
它应该遵循什么编码规范
完成后应该做什么（post comment？改 issue 状态？开新 issue？）

3. Squad Instructions 要写到" if-else "级别

如果你用 Squad 做流水线，Instructions 的颗粒度直接决定流转会不会卡死。不要写"按流程处理"这种空话，要写"如果出现 X，派给 Y；如果出现 Z，派给 W"。Leader 是一个没有直觉的调度器，它只能按你写的规则匹配。建议每调整一次规则，就用手动触发测试一次，看 Leader 的委派评论是否符合预期。

4. 用 Skill 封装重复的知识

如果你发现多个 Agent 都需要知道"怎么部署这个服务"或"怎么跑测试套件"，把它做成 Skill。一次编写，到处 attach。注意 Skill 修改后，只有新创建的 task 会用到新版本，正在运行的 task 继续使用旧版本。

5. 谨慎对待第三方 Skill

前面说了 ClawHavoc 的事。导入任何外部 Skill 前，读一遍 SKILL.md 和它附带的所有文件。你不知道里面藏了什么 prompt injection 或恶意指令。敏感项目只用自己写的 local skill。

6. 区分 Workspace skill 和 Local skill

团队协作用 Workspace skill——导入一次，所有队友的 Agent 都能用。Local skill 适合本地测试，或者内容涉及敏感本地资料的场景。

7. 合理设置超时预期

Task 的 running timeout 是 2.5 小时。如果你的 Agent 通常需要更久（比如大规模重构），考虑拆分成多个 issue。超时的 task 会自动重试一次，但如果重试也超时，问题还是没解决。

8. 用 Autopilot 的 create issue 模式

Run-only 模式虽然干净，但执行记录藏在 Autopilot 的 history 里，不容易发现。Create issue 模式让每次执行都在 issue board 上留下痕迹，方便追踪和审计。

9. 监控 Autopilot 的失败

Autopilot 失败不通知、不自动重试。重要的 Autopilot 自己设计监控：让 Agent 成功后在 issue 里 comment，失败了就通过"缺少 comment"来发现。

10. 给 Project 绑定 Resources

如果 project 涉及 GitHub 仓库，把 repo attach 到 project 的 Resources 里。这样 project 下的 issue 被 assign 给 Agent 时，Agent 自动获得这些 repo 的读写上下文。

11. 手动 rerun 时理解 session 的行为

自动重试会继承前一次的 session——Agent 可以接续之前的对话和文件状态。但手动 rerun（multica issue rerun）是全新的 session，这是设计意图：你手动 rerun 说明之前的结果有问题，继续同一个 session 可能会复现同样的错误状态。

12. Daemon 必须保持在线

Agent 能否工作完全取决于绑定的 runtime 是否在线。如果 daemon 关了、网络断了、机器休眠了，Agent 就停转了。新任务会 queued，等 runtime 恢复后自动 pickup。

如果你是团队里唯一跑 daemon 的人，考虑一下：你关机后，整个团队的 Agent 就都停摆了。

13. 选择合适的 AI 工具

不同 AI 工具的能力差异很大。文档里有完整的 Providers Matrix，特别关注这几点：

Session resumption 支持（多轮任务能否接续上下文）
Skill injection 路径（skill 文件实际放到哪里）
MCP 支持程度（目前 Claude Code 是真正消费 MCP 的）

Claude Code、Copilot、Hermes、Kimi、Kiro CLI、OpenCode、OpenClaw、Pi 支持 session resumption；Codex 和 Cursor 的代码存在但不可用；Gemini 不支持。

14. Rate limit 了怎么办？Multica 能自动切换模型吗？

不能。 这是很多人拿到 Multica 后第一个碰壁的地方——Claude Code 跑一半触发了 rate_limit_error，任务直接失败，不会自动换到另一个模型重试。

从 Multica 的角度看，rate_limit_error 属于 agent_error，是 non-retryable 的失败原因。文档明确说了，agent_error"不会自动重试——底层问题反复重试只会永远循环"。所以 Multica 不会帮你做自动 fallback。

从 Claude Code 本身的角度看，它也不支持运行中自动切换模型或 API key。Claude Code 启动时读取 settings.json（或环境变量）决定用哪个模型，一旦启动，执行过程中 rate limit 就是硬性停止。不存在"暂停、换配置、继续"的机制。

那实际怎么办？

方案一：多 Agent + 手动切换（最稳）

建两个 Agent，比如 dev-sonnet（绑定 Claude Code，默认用 Sonnet）和 dev-haiku（绑定 Claude Code，通过环境变量 ANTHROPIC_DEFAULT_SONNET_MODEL 或 --model 参数指向另一个模型，或者干脆绑定 Codex 作为完全不同的 provider）。当 dev-sonnet 因为 rate limit 失败时，你手动把 issue reassign 给 dev-haiku。

手动 rerun（multica issue rerun）时，如果指定了具体 task ID，会复用那个 task 的 Agent，不一定是你想换的那个。所以更稳妥的做法是：在 UI 里直接改 assignee，再手动触发 rerun。

方案二：Squad 做降级路由（理论上可行，实际很脆）

你可以让 Squad Leader 在每次被触发时读取 issue 的执行历史，发现上一次的失败原因是 rate limit，于是改派另一个成员。但这里有三个坑：

Leader 不一定能准确解析失败原因（它读的是评论和 activity，不是系统日志）
如果 rate limit 导致的是 timeout（2.5 小时没返回），失败原因可能是 timeout 而不是 agent_error，Leader 更难判断
整个流程至少多一轮 Leader 的触发和执行，延迟很高

方案三：从根上避免 rate limit

与其琢磨怎么 fallback，不如控制调用频率：

不要把太细碎的任务丢给 Agent（比如"把每个函数的注释补全"拆成几十个 issue），合并成一批处理
用 Haiku 或更便宜的模型做预筛选和简单任务，把 Sonnet/Opus 留给复杂实现
如果你在用 Anthropic API，考虑申请 rate limit 提升；如果用 AWS Bedrock 或 GCP Vertex，rate limit 模型完全不同，可以同时配置多个入口

关于"切换 settings 文件"

有人想：能不能准备两个 settings.json，rate limit 了就自动换另一个？Claude Code 支持项目级的 .claude/settings.json，但 Multica 的 daemon 每次都在一个临时隔离目录里启动 Claude Code，你没法预知那个目录是什么，更没法动态塞配置文件进去。Agent 的 custom environment variables 是 Multica 唯一能在启动时注入的变量，可以用来传 ANTHROPIC_API_KEY 或 ANTHROPIC_DEFAULT_SONNET_MODEL，但仍然是启动时配置，不是运行时切换。

六、自托管 vs Cloud

Cloud 版 5 分钟就能连上，适合想快速尝试的团队。Self-host 适合对数据有严格控制要求的团队——核心差异只是 Server 放在哪里，隐私模型（代码和密钥留在本地）是一样的。

Self-host 需要注意配置 MULTICA_PUBLIC_URL，否则 webhook URL 会基于客户端的 API origin 组装，在某些反向代理场景下会出问题。

写在最后

Multica 的野心很明显：不是做一个"带 AI 功能的项目管理工具"，而是做一个"AI Agent 和人类一起工作的协作平台"。这个定位意味着它必须回答一个难题——Agent 不是人，不能参加会议、不能读 Slack、不能自己判断优先级。Multica 的做法是把 Agent 封装成"一等成员"，用和人类相同的界面来交互（assign、@mention、comment），同时让执行完全本地化。

这个设计选择很聪明。它避开了"把代码上传到云端让 AI 处理"的隐私噩梦，也让团队可以逐步引入 Agent——不需要推翻现有的工作流，只是在 assignee picker 里多了一个选项。

但也说实话，它现在还有不少粗糙的地方。Cloud runtime 还在 waitlist，MCP 支持主要是 Claude Code 在消费，Gemini 不支持 session resumption，很多页面的文档还写得不完整。

不过方向是对的。项目管理工具赛道已经卷了很多年，Multica 可能是第一个真正把"AI Agent 是团队一员"这个理念产品化的。值不值得用，取决于你的团队是否已经到了"我们有好几个 Agent，需要一个地方协调它们"的阶段。

如果到了，试试。

当前页面是本站的「Google AMP」版。查看和发表评论请点击：完整版 »