当前位置：

社区首页

电脑数码

软件应用

服务软件

文章详情

Agent 时代，我们怎么协作

一句话结论

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

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

Multigent 适合承担这个基础设施角色：它不替代老板、产品、开发、QA 或运维的判断，而是把他们之间反复传递的上下文、任务、状态和审批沉淀成一个可运行、可治理的 Agent 工作区。

github.com/multigent/multigent

https://multigent.dev/

新流程的优化目标

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

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

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

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

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

用自己的专业知识投喂 Agent，让它理解这个角色应该如何判断。
通过 review 结果校准 Agent，让它逐步输出符合预期的结果。
把反复出现的判断、检查项和操作步骤沉淀成 prompt、playbook、task template 和 skill。
在关键风险和异常场景介入，而不是在每一步同步推动。

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

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

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

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

Multigent 任务看板

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

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

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

但 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 替代所有岗位"，而是把公司拆成几个可运行的层：

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

Multigent 提供的具体机制

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

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

这对公司的意义是：

老板的战略、原则和红线放在公司层。
产品、工程、运营等团队规范放在团队层。
PM、开发、QA、发布等岗位职责放在角色层。
某个产品或系统的技术背景放在项目层。
GitHub triage、PR review、发布检查、用户反馈处理等重复能力沉淀为 skill。

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

人和 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 可以按发布窗口执行检查清单。人不需要每次手动唤醒。

Heartbeat 调度

4. Inbox：让沟通异步化

Multigent 区分两类沟通：

普通 message：异步消息，不阻塞发送者。
confirm-request：需要人工确认的门控，任务暂停，等待回复。

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

"告诉你一个状态"：不应该打断别人。
"需要你做决定"：必须有明确审批记录。

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

是否批准某个高风险方案。
是否允许发版。
是否接受某个延期或范围调整。
是否对外发布某段内容。

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

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

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

可视化流程编排

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

旧流程

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

新流程

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

产品从"写 PRD 的中转站"变成"PM Agent 的责任人"：负责投喂产品判断、校准需求拆解、确认优先级和边界。
开发从"亲自完成所有实现细节"变成"Dev Agent 的责任人"：负责投喂技术背景、review 方案和代码、把常见修复路径沉淀成规则。
QA 从"人工点一遍"变成"QA Agent 的责任人"：负责定义测试策略、校准测试矩阵、确认质量门禁。
运维/发布从"手动上线"变成"Release Agent 的责任人"：负责发布策略、回滚策略和风险控制。
老板从"同步调度器"变成"方向、资源和关键风险的最终决策者"。

具体例子：Agent 的 Plugin / Connector 能力

以最近 Agent 增加 Plugin 和 Connector 能力为例，旧流程大概是：

这个流程本身并不差。前后端需要联调，不是因为需求背景不一致；如果大家都遵循同一份接口文档，接口语义可以是对齐的。联调真正暴露的通常是工程集成问题，例如实现细节、环境配置、测试数据、鉴权、错误码、边界状态、前端状态展示和接口文档之间的细微差异。

问题在于：每个人都有自己的本地 Agent，Agent 跟着个人走，而不是跟着这个功能工作流走。

这些 Agent 都有用，但它们默认不是一个项目小队。很多信息仍然靠人同步、靠人转述、靠人提醒下一步。

使用 Multigent 后，更合理的组织方式是把这个需求作为一个 project 来推进。由 project 承载这个需求涉及的成员、Agent、任务、流程、上下文和运行记录：

未来更理想的结构是：

这个 project 下配置的不是"每个人自己的私有 Agent"，而是一组面向流程的角色 Agent：

人仍然负责判断、接管和 review，但角色发生变化：每个成员不只"使用自己的 Agent"，而是分别成为对应角色 Agent 的责任人。他们用自己的专业知识训练和校准 Agent，让 Agent 后续能更稳定地替自己完成确定性工作。

Agent 负责在统一上下文和任务系统里持续推进；人负责让这个 Agent 越来越像一个合格的 PM、设计、前端、后端、QA 或发布角色。

自动流转应该怎么发生

这里要说清楚：Multigent 不是让所有事情"全自动无人驾驶"。它把流程拆成两类：

确定性工作：Agent 可以自动做，完成后自动进入下一步。
判断性工作：Agent 准备材料，发 confirm-request 给对应 human owner。

以 Plugin / Connector 需求为例，流程可以这样跑：

阶段 触发方式 Agent 自动做什么 人做什么 下一步如何流转 需求进入 human / PM 创建 project task pm-agent 汇总讨论记录、飞书文档、已有 PRD 草稿，整理目标、非目标、open questions 产品负责人确认产品方向确认后，pm-agent 创建设计/架构/拆分任务产品与设计 pm-agent 创建 design task design-agent 根据 PRD 整理页面、状态、交互清单设计负责人 review / 修改设计 design-agent 完成后通知 pm-agent / frontend-agent 技术拆分 pm-agent 或 tech owner 创建 architecture task 后端相关 Agent 整理 Plugin / Connector 的领域模型、接口边界、数据流、风险技术负责人 review 技术边界确认后自动创建 frontend/plugin/connector/qa 任务并行开发任务进入各 Agent 队列 frontend-agent、plugin-agent、connector-agent 按任务实现；遇到不确定点请求确认各开发负责人接管、补充、review 各任务 done 后，自动通知 integration / qa 联调前端和后端任务都完成后触发 integration task integration task 检查接口实现、环境、测试数据、鉴权、错误码、边界状态和 UI 状态前端与后端 owner 处理需要判断的问题集成问题自动拆成 bug task 回流到对应 Agent QA integration task 通过后触发 QA task qa-agent 基于 PRD、接口文档、设计状态生成 test matrix 并执行/辅助验证 QA 负责人做关键验证和质量判断 Bug 自动创建到 frontend/plugin/connector 对应 Agent Bug 修复 qa-agent 创建 bug task 对应 Agent 修复并输出 summary、变更点、验证方式对应开发 owner review 修复完成后自动回到 qa-agent 复测发布准备 QA blockers 清零后触发 release task release-agent 生成发布 checklist、风险、回滚方案、release note 运维 / release owner 确认上线高风险动作必须 human approve 复盘沉淀 release 完成后触发 retrospective task pm-agent 汇总周期、Bug 类型、返工点、可沉淀 skill 产品 / owner review 复盘更新 prompt、playbook、skill、模板

这张表里的关键点是：不是所有步骤都靠人肉驱动。

人主要驱动的是产品判断和关键确认；一旦任务拆出来，后续很多流转可以由 Agent 根据状态触发：

design task done -> 通知 frontend-agent。
backend API task done -> 通知 frontend-agent / integration task。
frontend + backend 都 done -> 创建 integration task。
integration 发现问题 -> 创建 bug task 给对应 Agent。
bug fixed -> 回到 qa-agent 复测。
QA blockers 清零 -> 创建 release readiness task。
release done -> 创建 retrospective / skill update task。

短期如果工具层还没有完全自动化这些触发，也可以先由 pm-agent 的 wakeup 定期扫描任务状态来推进。重点是：人不再逐条提醒"下一步该谁做"，而是让 Agent 按任务状态和 playbook 推进；人把专业判断补给 Agent，让它下一次更少依赖人。

人和本地 Agent 怎么过渡

这个流程不要求一开始取消每个人的本地 Agent。

短期可以这样做：

每个人仍然可以用自己的本地 Agent。但正式任务、上下文、状态、summary、Bug、QA 结果必须回到 Multigent project。

中期可以把这些本地 Agent 纳入 Multigent 管理：

frontend-agent 由前端负责人主要接管 plugin-agent 由后端负责人主要接管 connector-agent 由后端负责人主要接管 qa-agent 由 QA 负责人主要接管

这样保留每个人熟悉的协同开发方式，同时让 Agent 的工作不再散落在个人机器和个人会话里。人的主要目标也从"我每次都亲自指挥这个 Agent"逐步变成"我负责把这个角色 Agent 调到能稳定产出"。

长期更理想的是按项目 / 模块边界配置 Agent，而不是按人头配置 Agent。人可以接管 Agent，但 Agent 属于项目流程。

这个需求会沉淀什么（让流程知识与经验固化）

Plugin / Connector 做完后，不应该只留下 PRD、设计稿、代码和测试记录，还应该沉淀出可复用资产：

Context：Plugin / Connector 的定义、边界、接口约定、权限、安全、UI 状态、测试策略。
Task templates：跨前后端功能开发模板、API contract 模板、联调模板、QA test matrix、发布 checklist。
Skills：connector-api-review、frontend-backend-integration-check、qa-cross-functional-feature-test、release-readiness-check。
Role rules：PM 复杂功能必须输出 non-goals；后端跨模块必须先冻结 API contract；QA 必须提前生成 test matrix；release 必须检查配置、权限和回滚方案。
ROI 记录：这个 project 花了多少 Agent run、多少人工确认、多少 Bug、哪些环节返工最多、哪些 skill 值得固化。

这才是从"每个人用自己的 Agent 干活"升级到"公司用一支 Agent 小队交付功能"。