Agent 时代，我们怎么协作

[plane]

一句话结论

AI Agent 会先改变个人效率，然后改变公司结构。

如果只是让每个人各自使用 AI Agent ，效率会提升，但提升有限；真正的跃迁，来自把公司流程改造成一套 Agent 可参与、可交接、可审计、可持续运转的协作架构。

新流程的优化目标

新流程的目标不是"让 Agent 多做动作"，也不是"让每个人多一个 AI 助手"。真正目标是：

用更少的人类同步介入、更少重复 context 投喂、更可控的 token 成本，稳定交付符合预期的业务结果。

这意味着，人和 Agent 的关系要发生变化。

旧流程里，人经常是流程的驱动者：人解释背景、人分派任务、人提醒下一步、人检查结果、人修正错误。Agent 只是某个人手上的工具。

新流程里，人应该成为对应角色 Agent 的责任人和流程构建者：

• 用自己的专业知识投喂 Agent ，让它理解这个角色应该如何判断。

• 通过 review 结果校准 Agent ，让它逐步输出符合预期的结果。

• 把反复出现的判断、检查项和操作步骤沉淀成 prompt 、playbook 、task template 和 skill 。

• 在关键风险和异常场景介入，而不是在每一步同步推动。

换句话说，人的目标不是永远亲自带着 Agent 干活，而是把自己的专业能力逐步转移到对应角色 Agent 身上，让它能够替自己完成越来越多确定性工作，例如修 Bug 、补测试、整理接口差异、生成测试矩阵、准备发布检查。

这个目标不能一步到位。更现实的路径是三阶段：

阶段	人的角色	Agent 的角色	优化目标
阶段 1：人主导，Agent 入系统	人仍然主要驱动和接管 Agent	Agent 的任务、状态、输出、日志进入 agencycli	先让 Agent 工作可见、可追踪、可复盘
阶段 2：Agent 主动推进，人做关键确认	人主要 review 、补充专业判断、批准高风险动作	Agent 根据任务状态和 playbook 自动推进下一步	减少人肉提醒和重复 context 投喂
阶段 3：Agent 小队自主运转，人处理异常和验收	人成为角色责任人、流程校准者、最终验收者	Agent 小队完成大部分确定性工作	用更少介入和 token 稳定交付预期结果

所以，要优化的不是"有没有 Agent"，而是 Agent 是否能被组织、被校准、被度量，并逐步承担原本需要人反复推动的工作。

为什么现在需要重新设计协作方式

过去的软件团队协作默认是围绕人设计的：

这个流程在纯人类团队里是合理的。人会开会，会看飞书文档，会在脑子里补齐背景，也会在沟通中自动修正理解偏差。

但 Agent 不一样。Agent 不会天然知道哪份文档是最终版，不会自动继承会议室里的共识，也不会稳定记住另一个人刚刚告诉另一个 Agent 的背景。

当 Agent 开始进入产品、开发、测试和发布环节，旧流程的问题就不再只是"沟通成本高"，而是：公司还没有为 Agent 这种新型劳动力重新设计协作方式。

1. Agent Context 已经在发生，但缺少统一管理机制

很多公司都有飞书、云文档、会议纪要、项目文件夹、研发规范和历史记录。对人来说，这些材料通常是够用的：开过会的人知道背景，参与过讨论的人知道取舍，老同事知道哪个文档更可信。

真正的问题在 Agent 侧：这些知识当然可以变成 context ，也正在通过每个人的 prompt 、复制文档、贴会议结论、调用飞书 CLI 或 MCP 的方式变成 context 。问题是这个过程太临时、太个人化、太依赖人。

文档虽然存在，工具也能访问，但对 Agent 来说经常是散的、重的、版本不明确的、难以自动同步的。每个人手上的 Agent 拿到的 context 不一样：老板的 Agent 知道战略，产品的 Agent 知道需求讨论，开发的 Agent 知道代码细节，QA 的 Agent 知道测试问题，但它们缺少一套统一、分层、可维护的上下文管理机制。

结果不是"人混乱"，而是"Agent 混乱"：

• 同一个需求进入不同 Agent 后，理解可能不一致。

• 哪份文档是最终版、哪些信息已过期，Agent 很难自己判断。

• 每次启动 Agent 前都要重新找文档、补背景、贴结论，容易漏 context 。

• Prompt 越写越散，团队规范、项目背景、岗位职责无法稳定复用。

• 会议纪要、历史判断和执行经验没有沉淀成 Agent 可复用的 playbook / skill 。

• Agent 的能力被个人使用习惯限制，无法上升为公司级生产力。

一句话说：问题不是"知识有没有变成 context"，而是"context 有没有被统一管理"。Agent 时代，公司需要的不只是文档库和工具连接，而是一套能持续维护、分层组织、稳定注入 Agent 的 Context System 。

2. 人仍然在做 Agent 的 Context 搬运工

今天很多团队使用 Agent 的方式，本质上还是人在给 Agent 当翻译。

老板把想法讲给产品，产品整理后讲给开发，开发再把背景讲给自己的 Coding Agent ，QA 又重新把需求讲给测试 Agent 。看起来每个岗位都用上了 Agent ，但 Agent 并没有真正进入公司流程，只是被人一次次临时调用。

每多一层转述，就多一层损耗：

• 需求背景被压缩。

• 取舍原因被省略。

• 边界条件被遗漏。

• Agent 每次都要重新被喂一遍 context 。

如果上下文仍然靠人搬运，Agent 就只能提升局部效率，无法形成全链路协作。真正应该发生的是：Context 在系统里流动，Agent 按角色读取自己需要的部分，人只在必要时补充判断。

3. 旧流程浪费了 Agent 的持续 loop 能力

传统流程默认工作由人推动：人开会、人派任务、人提醒、人问进度、人决定下一步。人不在线，流程就慢下来；人没有看到消息，任务就停在那里。

但 Agent 最有价值的能力之一，是可以持续 loop：

• 定期醒来。

• 检查任务状态。

• 处理 pending 任务。

• 发现 blocked 。

• 请求确认。

• 完成后继续找下一件事。

如果公司流程仍然要求"人上线后再叫 Agent 做"，Agent 就只是一个更聪明的聊天窗口，而不是一支能持续工作的队伍。

Agent 时代的流程应该围绕任务状态流动，而不是围绕人的在线时间流动。人的位置应该从同步调度器，转向角色 Agent 的责任人、异步审核者、异常处理者和关键决策者。

4. Agent 自主执行需要新的权限、边界和质量门禁

当 Agent 只是帮个人写一段代码、总结一份文档时，权限边界不明显。

但当 PM Agent 能派任务，Dev Agent 能改代码，QA Agent 能验证，Release Agent 能准备发布时，它们就不再只是工具，而是在公司流程里承担角色。

角色一旦能自主执行，就必须有组织级边界：

• 哪些任务可以自动做。

• 哪些动作必须 human approve 。

• 哪些质量检查必须通过。

• 哪些风险必须升级。

• 哪些对外动作绝不能自动执行。

否则 Agent 带来的不是效率提升，而是风险放大。质量也不能再主要依赖"最后大家预发点一遍"，而应该分布到 Agent 执行链路的每一步：开发时测试、提交时 review 、QA 时回归、发布前 checklist ，异常才升级给人。

5. 没有统一运行记录，就无法衡量 Agent ROI

如果每个人都在自己的聊天窗口里使用 Agent ，公司很难回答几个关键问题：

• Agent 到底完成了多少任务？

• 失败最多的是哪些场景？

• 哪些任务最值得自动化？

• 哪些人工确认其实可以减少？

• token 成本花在哪里？

• 哪些 prompt 、playbook 或 skill 真的有效？

没有统一的任务、日志、成本和结果记录，Agent 的价值就停留在个人体感层面。老板只能感觉"大家好像更快了"，但无法判断哪里应该加码、哪里应该收缩、哪里应该沉淀为标准流程。

Agent 要从个人效率工具变成公司资产，第一步就是让它的工作看得见、算得清、复盘得了。

新协作架构的核心思想

新的流程不是"让 Agent 替代所有岗位"，而是把公司拆成几个可运行的层：

agencycli 的价值在于，它把这些层做成了一个可以实际运行的本地工作区，而不是只停留在组织方法论上。

Multigent 提供的具体机制

1. 分层 Context：让 Agent 继承组织知识

Multigent 的上下文不是每个 Agent 各写一份，而是按层组合：

这对公司的意义是：

• 老板的战略、原则和红线放在公司层。

• 产品、工程、运营等团队规范放在团队层。

• PM 、开发、QA 、发布等岗位职责放在角色层。

• 某个产品或系统的技术背景放在项目层。

• GitHub triage 、PR review 、发布检查、用户反馈处理等重复能力沉淀为 skill 。

这样做的收益不是"prompt 更整齐"，而是减少重复解释和上下文漂移。修改一条角色规则，可以同步到所有同类 Agent ；新增一个项目，可以复用既有团队和角色能力。

2. Agent 友好的任务系统：让任务不只是给人看，也能被 Agent 执行

公司可能已经有 Linear 、飞书任务、项目管理表格或其他任务系统。问题不在于"有没有任务管理"，而在于这些系统最初是面向人设计的。

人看到一个任务标题，可以结合会议记忆、上下游关系和团队默契去补全缺失信息； Agent 不行。Agent 需要更明确的输入：目标是什么，证据在哪里，哪些不做，验收标准是什么，失败后怎么处理，完成后通知谁。

multigent 的任务系统更像是 Agent 工作流适配层：它不是要替代所有项目管理工具，而是把任务变成 Agent 能直接消费、执行、回报和交接的数据对象。一个任务不只是"有人负责"，还包含 prompt 、优先级、状态、依赖、重试、运行日志、完成总结和必要的人工确认。

这会让研发流程从：

变成：

这不是增加流程负担，而是把"人脑能补齐、Agent 补不齐"的信息显式化。任务越结构化，Agent 越能自己推进；任务越像一句聊天消息，人就越需要反复救场。

3. Heartbeat 和 Wakeup：Agent 可以主动工作

如果 Agent 只能在人打开聊天窗口时工作，它仍然只是"个人工具"。multigent 的 heartbeat 机制让 Agent 按计划醒来：

• 有任务时，按优先级处理队列。

• 队列为空时，执行自己的 wakeup playbook ，主动巡检新问题。

• 通过 cron 定期生成日报、周报、巡检、计划等任务。

• 同一 Agent 不会重叠执行，避免重复跑和状态冲突。

对公司来说，PM Agent 可以定期巡检用户反馈和需求池，QA Agent 可以定期检查待验证变更，发布 Agent 可以按发布窗口执行检查清单。人不需要每次手动唤醒。

4. Inbox：让沟通异步化

agencycli 区分两类沟通：

• 普通 message：异步消息，不阻塞发送者。

• confirm-request：需要人工确认的门控，任务暂停，等待回复。

这正好对应企业里的两种情况：

• "告诉你一个状态"：不应该打断别人。

• "需要你做决定"：必须有明确审批记录。

理想状态下，老板不再被每个中间状态打扰，而是收到少量高质量的确认请求。例如：

• 是否批准某个高风险方案。

• 是否允许发版。

• 是否接受某个延期或范围调整。

• 是否对外发布某段内容。

5. Run log 、Telemetry 和 Web 控制台：让 Agent 工作可观察

Agent 自主工作不等于黑箱工作。agencycli 会记录运行日志、任务状态、消息、token/cost 统计，并通过 Web 控制台展示任务、消息、调度、上下文、skills 、运行记录等信息。

这对公司管理很关键：老板和团队不需要盯着每个 Agent 的聊天窗口，而是看系统里的任务流、阻塞点、成本和输出。

对公司研发流程的改造示例

旧流程

这个流程的优点是控制感强，责任分工清楚。缺点是上下文传递长、等待多、同步会议多、预发验证依赖人肉检查。

新流程

这里不是取消产品、开发、QA 、运维，而是改变他们的位置：

• 产品从"写 PRD 的中转站"变成"PM Agent 的责任人"：负责投喂产品判断、校准需求拆解、确认优先级和边界。

• 开发从"亲自完成所有实现细节"变成"Dev Agent 的责任人"：负责投喂技术背景、review 方案和代码、把常见修复路径沉淀成规则。

• QA 从"人工点一遍"变成"QA Agent 的责任人"：负责定义测试策略、校准测试矩阵、确认质量门禁。

• 运维/发布从"手动上线"变成"Release Agent 的责任人"：负责发布策略、回滚策略和风险控制。

• 老板从"同步调度器"变成"方向、资源和关键风险的最终决策者"。

预期收益

1. 减少 Agent 上下文损耗

分层 context 和 task prompt 让信息不再只靠人复制给 Agent 。需求背景、角色规则、项目约束、历史决策和执行记录可以被 Agent 稳定读取。

2. 缩短等待链路

Agent 可以通过任务队列和 heartbeat 自主推进。人只在必要时审批，不再是每一步的入口和翻译器。

3. 提高流程一致性

同类工作通过 role prompt 、wakeup playbook 和 skill 固化下来。比如每次派发开发任务都要求包含问题、证据、验收标准、风险和非目标，就能减少"说不清楚就开干"。

4. 降低重复劳动

高频流程可以沉淀为 skill：issue triage 、PR review 、QA checklist 、发布检查、日报、用户反馈分类。越用越像公司自己的 Agent 操作系统，而不是一堆临时 prompt 。

5. 增强管理可见性

任务状态、消息、运行日志、token/cost 、OKR 、milestone 可以集中观察。管理者看到的是 Agent 工作系统，而不是分散在聊天软件、文档、代码仓库和个人 Agent 会话里的碎片。

需要诚实面对的边界

这套模式不是无成本的，也不是立刻适合所有公司全量替换。

1. 需要先定义好角色和边界

如果 PM 、Dev 、QA 、Release 的职责不清楚，Agent 只会放大混乱。引入 Multigent 前，至少要定义：

• 哪些任务可以自动推进。

• 哪些动作必须人工确认。

• 哪个 Agent 有权给谁派任务。

• 哪些信息必须沉淀到项目文档、角色规则、skill 或 Agent 可用 context 。

2. 不能把高风险决策交给 Agent

资金、合同、对外发布、生产发版、数据删除、客户承诺等不可逆动作，仍然需要人工审批。Agent 可以准备材料、给出建议、执行通过后的动作，但不应该自行拍板。

3. 需要接受"流程产品化"

旧流程靠人脑补和口头补充，新流程要求把规则写进 prompt 、playbook 、skill 和任务模板。前期会有整理成本，但这是从"个人会用 AI"升级为"公司会使用 Agent 劳动力"的必要成本。

4. 需要在真实流程中持续校准

这套流程不会一上来就完美。Agent 不是装上就自动理解公司运转方式的员工，它需要在真实任务里不断校准。

一开始会遇到很多需要调节的地方：

• prompt 写得不够清楚，Agent 理解偏了。

• 任务模板不够结构化，执行结果不稳定。

• wakeup 频率太高或太低，导致打扰过多或响应变慢。

• 权限边界不够清楚，Agent 不知道什么时候该停下来请求确认。

• skill 没有沉淀好，同类任务仍然反复解释。

• 与飞书、GitHub 、CI/CD 等工具的连接方式需要在实际流程里打磨。

这不是失败，而是 Agent 工作流产品化的必经过程。真正重要的是：每次失败都能被记录，每次修正都能沉淀到 prompt 、playbook 、skill 或流程规则里，让下一轮 Agent 做得更好。

建议的落地路径

第 0 阶段：选一个真实但可控的流程试点

不要一开始改造全公司。建议选一个链路清楚、重复性强、风险可控的流程，例如：

• 用户反馈 / Bug triage 。

• GitHub issue 到开发任务分派。

• PR review 到 QA 验证。

• 测试环境回归检查。

• 发布前 checklist 。

成功标准可以先定得务实：

• 50% 以上任务由 Agent 自动完成初步处理。

• 老板/负责人只处理明确的 confirm-request 。

• 每个完成任务都有 summary 和日志。

• 重复问题能沉淀为 playbook 或 skill 。

第 1 阶段：建立公司的 Context Grid

先创建最小组织结构：

并写清楚四类上下文：

• 公司层：目标、原则、不可触碰红线。

• 团队层：团队工作标准。

• 角色层：岗位职责、输入输出格式、升级条件。

• 项目层：产品背景、技术栈、关键路径、当前优先级。

第 2 阶段：把现有流程变成任务模板

不要追求复杂自动化，先把"好任务"定义清楚。

例如开发任务模板：

问题：
证据：
期望行为：
非目标：
验收标准：
风险：
完成后：

QA 任务模板：

对象：
变更范围：
必须验证：
可接受风险：
输出要求：

发布任务模板：

版本：
变更摘要：
发布前检查：
回滚条件：
需要人工确认的点：

第 3 阶段：配置 Agent Wakeup

每个关键角色配一个 wakeup playbook：

• PM Agent：巡检需求、分诊、派发任务、识别需要老板决策的事项。

• Dev Agent：处理开发任务、写测试、提交结果、遇到边界请求确认。

• QA Agent：验证 PR/测试环境、记录风险、退回问题或请求发布确认。

• Release Agent：执行发布 checklist 、观察结果、触发回滚建议。

第 4 阶段：只把关键决策推给人

明确人工确认规则：

• 可以自动做：调研、复现、测试、整理、草稿、内部任务分派。

• 需要确认：上线、合并、对外发布、客户承诺、资金、权限、删除数据。

• 只需通知：普通任务完成、低风险修复、日报和周报。

第 5 阶段：每周复盘并沉淀 skill

每周只看 4 个指标：

• Agent 自动完成了多少任务。

• 人工确认请求有多少，哪些可以减少。

• 哪些任务重复出现，可以沉淀成 skill 。

• 哪些失败来自上下文缺失，需要补充到公司/团队/角色/项目层。