AI Native 团队如何协同：从人肉接力到 Agent 任务网络

一家团队给需求、产品、研发和测试都配了 AI 工具。业务用模型整理市场反馈，产品十分钟生成 PRD，研发让 Code Agent 写代码，测试再让另一个模型生成用例。每个环节都比以前快，项目上线时间却没有明显缩短。产品文档里对“首单”的定义和研发理解不同，测试直到联调才发现结算服务会重新计算优惠，几份高速生成的产物把返工一起加速了。

局部产能提高以后，工作会更快地堆到下一个环节，审查和协调压力随之上升。如果流程仍靠人逐段搬运信息、解释差异和催促下一步，AI 只改变了每一段的生成速度，没有改变端到端流动方式。

本文讨论一个比“给团队增加几个 Agent”更具体的问题：当 Agent 开始参与需求、产品、研发、测试和运维，什么样的协同结构能够减少人肉接力，又不把决策权、权限和责任交给一群概率模型？

文章承接上一篇《企业级 AI Coding 为什么还没发生质变：从工具提效到知识供给链》。上一篇处理 Agent 如何获得跨团队知识，这一篇关注工作如何在多个角色与 Agent 之间流动。事实依据主要来自 DORA、SPACE、METR 的生产力研究，以及 Anthropic、OpenAI 公开的 Agent 工程实践；组织形态和协议设计属于本文的工程推演。

一、单点变快为什么会造成全局拥堵

软件交付是一条有依赖的工作流。需求是否清楚会影响方案，接口是否稳定会影响并行开发，代码质量会影响审查和测试，发布策略又决定故障恢复成本。优化其中一个环节，不会自动提高整个系统的吞吐。

假设产品每天能稳定整理两份可进入研发的需求，研发原本每天实现一份。Code Agent 把研发能力提高到三份，测试和评审仍只能处理一份。短期看，代码产量增长；两周以后，待审查变更、联调分支和测试环境争用一起增加。批量变大后，每个变更等待更久，冲突也更多。

DORA 2025 年 AI 辅助软件开发研究把 AI 描述为组织系统的放大器：它会放大已有的优势，也会放大流程薄弱处。DORA 较早的生成式 AI 影响报告还观察到，AI 使用与个人感知的生产力、心流改善同时出现，却与交付吞吐和稳定性下降相关。报告给出的关联结果不能证明 AI 导致了下降，但足以提醒团队，个人速度不能替代交付指标。

METR 在 2025 年开展的随机对照实验也提供了一个边界明确的负面结果：16 位熟悉自己开源仓库的开发者完成 246 个任务，在该实验与早期 2025 工具条件下，允许使用 AI 的任务平均耗时增加了 19%。这项研究不能外推到所有工程师和工具，研究者自己也列出了适用范围。它说明“模型更快生成代码”与“熟悉系统的人更快完成任务”之间存在大量中间成本。

协同问题通常藏在四类等待中：等另一个角色补信息，等上游做决定，等下游确认能否接收，等出现冲突以后重新对齐。AI Native 团队如果只优化产物生成，不处理这些等待，最终会得到更高的在制品数量，而非更短的交付周期。

二、AI 辅助与 AI Native 的差别在流程假设

“AI Native”没有统一工程定义。本文给它一个工作定义：流程在设计时就假设 Agent 能够读取状态、调用工具、产生工件和持续推进任务，人主要处理目标、取舍、授权与例外。

传统流程假设人是串联者。需求、PRD、技术方案、代码和测试报告分别待在不同系统里，人负责理解上一段输出，补充没有写下来的背景，再把它翻译成下一段能用的输入。协作软件记录状态，却很少能独立判断状态是否满足推进条件。

AI 辅助保留这副骨架。人在每个节点主动调用模型，复制材料、检查输出，再把结果粘到下一处。它能降低某些操作成本，但上下文仍存在人的会话里，跨阶段错误也由人发现。

AI Native 流程把可重复的串联责任交给系统：读取共享目标，检查前置条件，调用合适的 Agent 或工具，保存结构化工件，收集完成证据，并在遇到冲突或高风险动作时找到责任人。人不需要手工催每一步，却能看到为什么推进、依据什么、下一步会产生什么影响。

传统人肉接力、AI 辅助与 AI Native 任务网络的差别

图里的中间一栏很常见。给每个岗位一个 Copilot，仍然可能是人肉接力，只是每一棒跑得更快。右侧依靠共享任务状态和交接协议改变流动方式，增加 Agent 数量不会自行产生这种变化。

原文提出“串联者从人换成 Agent”，方向上抓住了生产侧变化，字面上却容易过度推导。稳定系统不会让一个模型独自拥有全部流程控制权。任务状态、超时、幂等、权限与审批适合交给确定性控制面；模型适合处理语义理解、方案生成、异常归因和工具选择。所谓 Agent 串联，是模型与工作流系统共同承担过去由人补位的协调劳动。

三、串联一项工作究竟包含哪些责任

“把上一份文档传给下一个 Agent”只覆盖了传输。完整交接至少包含六项责任。

第一，识别当前目标和作用域。系统要知道这次任务希望改变哪个业务结果，哪些内容明确不在范围内，以及哪些护栏不能突破。

第二，检查前置条件。技术方案开始前，业务规则是否已经确认；发布前，兼容性测试和回滚方案是否存在。没有前置检查，流程只是把不确定性向后推。

第三，转换工件。产品目标要变成可验收行为，方案要变成任务和接口契约，代码要变成可以审查的 Diff 与测试证据。每一次转换都有信息损失风险。

第四，维护状态。谁正在处理、等待什么、使用了哪一版知识、失败后从哪里继续，都不能只留在某段聊天记录里。

第五，执行权限与风险策略。读取数据、修改代码、创建工单、灰度发布和资金操作的授权等级不同。一个 Agent 能看见信息，不代表它可以据此采取所有动作。

第六，处理例外。规则冲突、目标变化、验证失败和外部系统超时都需要明确去向。系统必须知道何时重试、何时回退、何时暂停并请求人类判断。

人类过去能承担这些责任，是因为人会利用组织经验填补缺口，并愿意通过开会和私聊恢复流程。Agent 会让这些隐含责任暴露出来。想稳定接管串联，团队需要把它们写进任务协议、状态机和权限系统。

四、AI Native 团队需要五个协同平面

一个可运行的团队结构可以拆成五个平面：业务空间、控制面、知识面、执行面和证据面。它们是责任划分，不一定对应五套独立产品。

AI Native 团队的五个协同平面

业务空间划定一次闭环的目标、成员、Agent、资源和权限边界。它可以对应一个稳定业务单元，也可以对应一次跨团队项目。任务、知识版本、工件和事件在空间里共享作用域，群聊只是其中一种交互入口。

控制面保存目标、任务图、状态、策略和审批结果。模型可以建议下一步，控制面决定状态是否合法。例如测试失败以后允许回到实现阶段，却不能跳过修复直接进入发布；同一发布事件重复到达时，控制面根据幂等键避免执行两次。

知识面提供业务规则、领域模型、团队规范和仓库事实。上一篇讨论的知识供给链就在这里。它负责回答“当前任务可以依据什么”，同时暴露冲突、版本和来源。

执行面包含角色 Agent、工具和确定性服务。产品 Agent 可以整理需求与影响面，研发 Agent 生成方案和修改代码，测试 Agent 构造用例，运维 Agent 分析发布风险。上下文、工具、权限和评测目标决定如何拆分，无需照着组织职位逐一复制 Agent。

证据面保存任务过程中产生的可验证结果：需求决策、接口契约、Diff、测试报告、审批、外部系统回执和运行指标。控制面用证据判断是否可以推进，审计和复盘也依赖它。没有证据面，所谓协同只剩一串自然语言消息。

人横跨五个平面，但主要位于控制面上方。他们定义目标、解决冲突、批准高风险动作、处理系统没有覆盖的例外，并对最终结果负责。低风险路径运行顺畅时，人可以只看摘要；风险升高或证据不足时，系统把上下文和选项一起交给对应责任人。

五、业务空间应该按闭环划，不该照搬组织图

原文建议以“完整业务单元”作为边界，这个方向很重要，难点在于怎样判断完整。按部门划分通常太宽，按仓库划分又太窄。一个优惠业务可能涉及营销、订单、结算和风控，代码散在多个团队，却共同影响同一个用户结果。

可以用五个问题寻找边界：

是否存在一个可以被共同理解和衡量的业务目标？
从事件发生到结果反馈，主要链路能否在边界内闭合？
大部分必要知识与工具是否能够在同一权限域中访问？
冲突发生时，是否有一个明确的最终 Owner？
与外部单元的交互能否通过稳定契约表达？

如果目标写成“提高营销团队效率”，边界仍然模糊；写成“提高企业新客首单转化，同时保持补贴率和套利损失不超过护栏”，不同角色才有共同终点。业务、产品、技术和测试不再各自优化文档数量、开发速度或用例覆盖，而是围绕同一组结果与风险指标工作。

边界也不能追求完全自给。商品、支付、账号等平台必然被多个业务复用。AI Native 协同需要做的是把跨界调用变成带版本、责任人和服务承诺的契约，让 Agent 知道何时可以直接调用，何时需要外部团队确认。试图把所有依赖都纳入一个业务空间，会把空间扩大成另一个公司级平台，最终失去可治理性。

对于一次性的跨域项目，可以创建临时空间，引用各领域的知识和工具，并在项目结束后归档任务状态。被确认的新规则回到长期领域，项目空间不应该复制一份永久知识库。

六、多个 Agent 需要共享任务账本，而非共享一段聊天

多人协作常把群聊当作事实源：谁说了什么、最新决定是哪条，靠参与者自己判断。Agent 加入后，消息数量会增长得更快，模型还可能把提议误读为决定，把旧结论当成当前状态。

共享任务账本应把稳定状态从对话中提取出来。每个任务至少保存目标、当前阶段、输入工件、负责者、知识版本、权限、截止条件、未决问题和完成证据。聊天是讨论界面，账本才是运行状态。

一个最小任务信封可以写成：

task_id: promo-enterprise-first-order-2026q4
goal_ref: goal.enterprise-first-order-conversion.v2
stage: solution-review
owner: marketing-tech
inputs:
  - artifact: product-spec.v4
  - knowledge: coupon-stacking-policy.v3
constraints:
  - subsidy_rate <= 0.08
  - settlement_must_accept_locked_discount
permissions:
  read: [marketing, order, settlement]
  write: [proposal, task-plan]
  execute: []
unresolved:
  - enterprise_identity_cache_ttl
required_evidence:
  - cross-domain-contract-review
  - rollback-plan
next:
  on_pass: implementation-ready
  on_reject: product-clarification

角色 Agent 根据同一个任务 ID 工作，各自只得到所需的上下文和权限。产品 Agent 可以更新产品工件，不能修改代码；研发 Agent 可以提交实现方案，不能静默改变补贴护栏；测试 Agent 可以阻止进入发布，不能重写业务目标。

任务账本还解决恢复问题。某个 Agent 超时或模型版本切换以后，新实例可以从已确认状态继续，不需要重放所有聊天。系统也能回答“为什么进入发布阶段”，因为状态转换关联了具体证据和审批。

七、交接协议要表达事实、决定与未决问题

Agent 之间最危险的交接，是一段看起来完整的总结。总结压缩了过程，却可能把不确定性一起压掉。接收方看到流畅文本，很难区分哪些是已确认事实、哪个是模型推断、哪些问题仍然没有答案。

交接包需要把内容按语义分开：

{
  "taskId": "promo-enterprise-first-order-2026q4",
  "from": "product-agent",
  "to": "engineering-agent",
  "facts": [
    {"id": "coupon-policy.v3", "evidence": "ADR-042"}
  ],
  "decisions": [
    {"id": "decision-17", "approvedBy": "product-owner"}
  ],
  "assumptions": [
    {"text": "企业身份变更延迟不超过 5 分钟", "status": "unverified"}
  ],
  "openQuestions": [
    {"owner": "identity-team", "question": "缓存 TTL 的正式承诺是什么？"}
  ],
  "artifacts": ["product-spec.v4"],
  "acceptance": ["stacking-contract.feature"],
  "scopeExcluded": ["存量订单重算"]
}

事实需要来源，决定需要授权者，假设要保持未验证状态，未决问题必须有 Owner。接收 Agent 可以继续处理与未决问题无关的部分，也能在即将依赖它时主动暂停。这样既避免一遇到问题就等待，也防止模型把空白补成结论。

协议不要求所有工件都变成 JSON。PRD、技术方案和代码仍可以用最适合人类审查的形式保存；结构化元数据负责路由和状态，正文承载复杂语义，测试与外部回执提供机器可判定证据。把所有业务讨论强行塞进字段会丢掉细节，只保留长文又无法可靠编排，两者需要配合。

八、Agent 编排应由状态机托底

让多个 Agent 在群里自由决定“谁接下来做什么”，适合演示，不适合高风险生产流程。模型输出具有波动，同一消息可能触发重复动作；Agent 互相调用还可能形成循环，迅速消耗预算并制造冲突。

一条稳定路径通常是确定性外壳包住概率决策。工作流引擎或 Harness 保存状态机、重试、超时、幂等和预算；模型在指定节点完成语义任务，例如影响分析、方案比较、代码修改或失败归因。模型可以提出新增任务，控制面验证依赖和权限以后再写入任务图。

AI Native 研发任务的状态、门禁与回退路径

图里的每条前进边都有证据条件，每条回退边都有明确原因。产品规格通过业务 Owner 确认后才能进入方案；方案的跨域契约未确认时，编码可以处理局部准备工作，不能发布接口；自动测试通过也不代表可以直接上线，高风险变更仍要经过发布门禁。

Anthropic 的 Building Effective Agents建议先使用简单、可组合的模式，只在任务需要时增加自治。已有文章《Subagent 与多 Agent：任务拆分、通信与结果汇总》也讨论了多 Agent 的协调成本。组织协同更应该克制，因为参与者越多、状态越长、权限越广，自由对话的错误面越大。

九、人负责判断，不代表每一步都要点确认

“人定目标、做判断，Agent 串联执行”仍然需要细化，否则系统会落入两个极端。一个极端是 Agent 可以自动做任何事，风险不可控；另一个极端是所有动作都弹出确认，人变成审批机器人，协同成本没有下降。

门禁应该由风险决定：

动作	默认处理	人类介入条件
搜索知识、读取只读数据	自动执行并留痕	涉及受限数据或跨权限域
生成 PRD、方案、用例草稿	自动生成	发布为正式决定前由 Owner 确认
修改隔离分支、运行测试	自动执行	超出任务范围、预算或沙箱边界
创建可回滚的内部配置变更	策略允许时自动	影响范围扩大或验证不足
发布、资金、用户权益、安全策略	默认门禁	指定责任人批准，保留回执
目标冲突与规则例外	暂停并升级	由拥有业务责任的人作取舍

人的判断远比批准或拒绝丰富。人可能修改目标、接受某项风险、选择灰度范围、指定例外有效期，或决定停止任务。系统要把这些判断写成结构化决定，关联当时证据，避免后续 Agent 只知道结果、不知道适用范围。

专业角色不会因为 Agent 出现而完全融合。Agent 能够跨技术栈执行，减少岗位之间的机械边界；业务取舍、安全责任、架构演进和用户体验仍需要不同类型的专业判断。未来更稀缺的能力可能是审查一套完整方案、识别模型没有提出的风险，并愿意对取舍负责。

十、用一个促销需求走完整个任务网络

团队的目标是提高企业新客首单转化，同时保持补贴率不超过 8%，套利损失不高于当前基线。业务 Owner 将目标和护栏写入空间，运营 Agent 读取历史数据，提出三个候选策略。它只能生成分析，不能调整线上补贴。

产品 Agent 读取券叠加规则、企业身份定义和历史实验，生成产品规格。系统发现身份缓存 TTL 没有权威承诺，把问题分配给账号团队。其他部分继续推进，涉及实时身份变化的验收项保持阻塞。业务和产品 Owner 选择“企业首单券可与区域券叠加”的方案，决定记录进入任务账本。

研发 Agent 根据产品规格和知识底座识别出营销、订单、结算三个服务，生成接口契约与发布顺序。架构负责人确认营销负责资格，订单保存优惠快照，结算只校验已锁定结果。随后控制面把实现拆成三个有依赖的任务，各 Code Agent 在隔离分支工作。

测试 Agent 从业务护栏和接口契约生成测试矩阵，除了正常路径，还覆盖身份变更、重复支付、结算重算和旧客户端。它没有等所有代码完成才介入，测试契约与接口设计同时形成。实现合并后，流水线执行单测、契约测试和集成测试，并把结果关联到每条验收条件。

发布 Agent 检查变更范围、监控项、灰度比例与回滚脚本。补贴规则属于用户权益变更，系统请求指定 Owner 批准 5% 灰度。发布后，运营 Agent 追踪转化、补贴率和套利告警。若护栏越界，确定性策略自动停止扩量并通知人，不能让模型权衡后继续放量。

任务完成时，产品决定、接口契约、测试证据和运行结果形成一条可追溯链。仓库事实自动进入知识更新候选，新的业务规则由 Owner 审核后发布。下一次调整不必从群聊和个人记忆重新拼装全部背景。

这条流程里，Agent 处理了信息搜集、工件转换、执行和状态推进；人类出现于目标、跨域责任、风险接受和例外判断。等待与重复转述减少了，责任仍然有明确归属。

十一、“软件是固化的知识”是有用但有限的比喻

原文把软件理解为被固化的知识，这个比喻能解释为什么业务规则可以由 Agent 动态执行，也可以被编译进确定性系统。例如补贴上限是一条业务知识，它可以先存在于规则对象里，随后落成策略配置、校验代码和契约测试。

软件仍然比知识多出几类责任。它要管理状态和并发，提供性能与可用性保证，执行访问控制，处理网络失败，并通过稳定接口与外部世界交互。自然语言规则没有幂等语义，也不会自动给出事务边界。把知识直接交给 Agent 动态解释，结果可能随模型、Context 和调用顺序变化。

更准确的说法是：软件把一部分经过确认的业务决定编译成可重复执行的机制。哪些部分应该固化，取决于确定性、延迟、成本、安全和审计要求。高频稳定规则适合进入代码或规则引擎；低频、探索性、需要综合非结构化信息的步骤可以由 Agent 执行；价值取舍与高风险例外继续由人负责。

这个视角还改变了研发产物。代码之外，团队还会交付知识对象、可执行规则、Agent Skill、工具接口、任务协议和验证证据。它们共同决定业务怎样运行，代码仓库无法单独承载全部事实。

十二、协同漂移的六种失败方式

第一类风险是目标分裂。运营 Agent优化转化，研发 Agent优化交付速度，测试 Agent追求覆盖率，每个局部指标都改善，补贴成本却失控。共享目标必须同时包含结果和护栏，局部 Agent 的奖励不能覆盖全局约束。

第二类风险是语义漂移。产品 Agent 把“首单”解释成首次创建订单，研发按首次支付实现，测试又按首次成功签收验收。交接包需要引用同一知识 ID 和版本，关键术语进入契约测试，不能在每个节点重新自然语言改写。

第三类风险是权限洗白。前一个 Agent 没有发布权限，却把建议交给拥有高权限的运维 Agent，后者只检查消息来源，没有重新验证任务授权。权限必须绑定原始用户、任务和目的，不能因为 Agent 间转交而升级。

第四类风险是反馈回路。监控 Agent 创建缺陷，研发 Agent 提交修复，测试失败又创建新缺陷，几个自动触发器可能围绕同一事件循环。任务 ID、去重键、最大迭代和人工接管阈值需要由控制面强制执行。

第五类风险是隐藏的人类劳动。Agent 生成更多方案、代码和测试，专家审查量随之增长。若团队只统计自动产出，会把成本转移误判为提效。审查时间、被退回比例和上下文切换都要进入测量。

最后是责任真空。系统显示“产品 Agent 已批准”或“测试 Agent 已验收”，却没人对业务结果负责。Agent 可以执行规则和提供建议，组织仍需要为目标、策略和高风险动作指定人类 Owner。

十三、如何衡量端到端协同是否变好

SPACE 框架强调生产力不能由单一活动指标表示，需要同时观察满意度与福祉、绩效、活动、沟通协作和效率流动。用它检查 AI Native 改造，可以避免只统计调用量、生成代码和 Agent 完成任务数。

更直接的交付指标包括：

从目标确认到可用结果的端到端周期，以及其中真正工作与等待各占多少；
每个任务的交接次数、澄清轮次、阻塞时间和重新打开次数；
一次验收通过率、线上缺陷、回滚和业务护栏违约；
人类在生成、审查、例外处理和恢复上的时间；
每个成功任务的模型、工具、基础设施与人工综合成本；
知识复用率、过期引用和因缺少事实导致的失败。

评测的单位应该是完整任务。选一类高频流程，保留改造前基线，再比较 AI 辅助和 Agent 串联两种方案。任务难度、风险和依赖数量要分层，否则简单任务比例变化会掩盖真实效果。

还应测量失败后的恢复。系统从工具超时、Agent 输出不合格或人工拒绝中恢复需要多久，是否能够从检查点继续，是否会重复外部动作。一个只在顺利路径上节省时间、失败后必须人工清场的流程，很难扩大自治范围。

十四、从一条交接开始改造

全公司一次切换到 AI Native 没有可行路径。更稳妥的起点是一条频繁、边界清楚、结果可以验证的交接，例如“已批准的产品规格进入研发方案”或“缺陷定位结果进入修复任务”。

先画出现有价值流，记录每个阶段的输入、输出、等待、补充信息和 Owner。不要急着做 Agent，先找出哪次交接最常返工，以及返工缺少的事实是什么。

接着定义共享任务账本和交接包。让上游 Agent 生成结构化候选，由人确认后进入下游；控制面保存状态与证据。第一阶段可以继续由人触发下一步，只验证工件质量和可追溯性。

协议稳定后，再把一个低风险状态转换交给系统自动推进，例如契约评审通过后创建三个仓库任务。接入超时、幂等、预算和回退，观察它是否真的减少等待，而非制造更多审查。

自治范围应由历史证据扩大。某类任务连续满足结果和风险指标后，可以减少人工门禁；一旦过期知识、越权或回滚增加，就收紧策略。团队最终得到一张会随运行结果调整的自治矩阵，“全面无人化”不再是目标。

业务空间、知识底座和工具平台也不必同时建全。可以复用现有工单、文档、代码托管和 CI，只增加统一任务 ID、结构化状态与 Agent 适配层。流程跑通以后，再决定哪些组件值得产品化。

结语

AI Native 团队的变化不在于组织图里多了一排机器人图标。它改变了工作如何被表示和推进：目标成为带护栏的任务契约，交接从自然语言转述变成可追溯工件，状态由控制面保存，Agent 调用知识与工具完成执行，人类在目标冲突、专业取舍和高风险动作上承担责任。

“Agent 成为串联者”更适合作为方向，而非运行时设计。实际系统需要确定性工作流托住状态、权限和恢复，让 Agent 处理其中难以规则化的语义工作。没有这层结构，多 Agent 只会增加新的沟通方；有了共享目标、任务协议和证据闭环，团队才可能把局部生成速度转化成端到端流动效率。

知识底座决定 Agent 能否理解业务，协同协议决定这些理解能否跨阶段保持一致，工具和 Harness 决定决定能否安全落地。三者共同建设，才有资格讨论生产侧的流程重构。

参考资料

《重构协同：关于 AI Native 团队的思考》（用户提供原文）
DORA State of AI-assisted Software Development 2025
DORA Impact of Generative AI in Software Development
Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity — METR
The SPACE of Developer Productivity — Microsoft Research
Building Effective AI Agents — Anthropic
Harness engineering: leveraging Codex in an agent-first world — OpenAI