把 Sharkly 这种把任务状态和执行记录共享给多人的协作模式引入开发团队后，我发现 AI

在公司推行 AI 编码 Agent 这段时间，我最大的感触是：AI 已经从一个「问答助手」变成了「团队成员」。以前我们用 AI 只是问个 API 怎么写，然后复制粘贴代码；现在是直接扔给 Agent 一个任务，让它自己去翻代码库、改文件、跑工具、修 Bug。但随之而来的问题是，当 AI 成了团队的一员，协作链路怎么跑通？

一个典型的场景是：开发 A 启动了一个 Agent 去写功能，写到一半时，开发 B 发现这个方案在另一个模块有冲突。在传统的协作模式里，B 必须先私聊 A，然后 A 回到自己的终端告诉 Agent 怎么改。这种由于 Agent 会话私有化导致的「沟通折返」效率极低。

我想分享一个比较有效的协作逻辑，就是把「任务本身」定义为共享上下文，而不是把 Agent 当作某个人的私有对话窗口。

区分「使用 AI」和「与 AI Agent 协作」

很多人把这两者混为一谈，但在实际落地中，这完全是两套工作流。

• AI 辅助（Assistance）： 比如我问 ChatGPT 一个接口怎么调用，或者让 Copilot 补全一个函数。这本质上是单次、点对点的指令响应。
• Agent 协作（Collaboration）： 这是一个持续的、面向目标的执行过程。比如我给 Agent 下达一个指令：给新 API 接口增加鉴权，更新测试用例，并确保现有接口不受影响。

这时候 Agent 会独立执行：检查仓库 → 修改代码 → 运行测试 → 汇报结果。在这个过程中，人类并没有消失。可能在执行到 50% 时，产品经理改了验收标准，或者 Reviewer 要求增加测试覆盖率。如果 Agent 的执行过程是透明且可介入的，那么人类和 Agent 就在参与同一个持续的工作流，而不是简单的「投喂 Prompt → 等结果」。

如何解决多人在同一个 Agent 会话中协作的问题

要实现真正的协作，必须打破「私有会话」的壁垒。我尝试在团队中引入 Sharkly，它的核心逻辑就是把需求、任务状态、讨论记录、执行历史和 Review 全部绑定在同一个任务 ID 下，而不是散落在每个人的私有 Prompt 或终端会话里。

在这种模式下，协作链路变成了这样：
1. 开发 A 启动任务，Agent 开始执行。
2. 开发 B 发现问题，直接在该任务的共享上下文中介入，修正方向。
3. Reviewer 看到 Agent 的执行记录，直接在对应步骤提出修改意见。
4. Agent 接收到来自不同角色的反馈，实时调整执行路径。

这样就避免了那种「 A 告诉 B，B 再告诉 AI」的低效传递。当执行记录和讨论记录同步时，任何人接手这个任务，都能立刻通过历史记录知道 Agent 之前尝试了什么、为什么失败，而不需要重新通过 Prompt 告知一遍背景。

对于我们这种需要多人协作的开发团队来说，把 Agent 的工作过程「公开化」和「任务化」，比追求一个完美的 Prompt 更有实际意义。