【AI原生组织】6-AI Native团队组建与基础设施搭建

[AI Native 团队组建与基础设施搭建](#AI Native 团队组建与基础设施搭建)
- [一、招了 5 个 AI 工程师，3 个月没产出](#一、招了 5 个 AI 工程师，3 个月没产出)
- [二、为什么 AI Native 团队不能照搬传统研发团队](#二、为什么 AI Native 团队不能照搬传统研发团队)
- - [2.1 康威定律在 AI 时代的复刻](#2.1 康威定律在 AI 时代的复刻)
  - [2.2 麦肯锡 2.5 万 + 4 万：人机比例是诊断结果，不是 KPI](#2.2 麦肯锡 2.5 万 + 4 万：人机比例是诊断结果，不是 KPI)
  - [2.3 AI 团队拓扑的四种基本摆法](#2.3 AI 团队拓扑的四种基本摆法)
  - [2.4 三类新角色：被低估的"AI 时代新岗位"](#2.4 三类新角色：被低估的"AI 时代新岗位")
- 三、人机配比怎么定，岗位怎么设
- - [3.1 三种配比模型：从 1:1 到 N:M](#3.1 三种配比模型：从 1:1 到 N:M)
  - [3.2 关键岗位设计：从"全栈工程师"到"复合型工程师"](#3.2 关键岗位设计：从"全栈工程师"到"复合型工程师")
  - [3.3 错误 vs 正确：岗位描述怎么写](#3.3 错误 vs 正确：岗位描述怎么写)
  - [3.4 选型理由：为什么 2-5 人 + 50-100 Agent 是起点](#3.4 选型理由：为什么 2-5 人 + 50-100 Agent 是起点)
- [四、基础设施四件套：从 AI 网关到 Skill 商店](#四、基础设施四件套：从 AI 网关到 Skill 商店)
- - [4.1 Step 1：统一 AI 网关（目的：凭证收敛 + 限流 + 审计）](#4.1 Step 1：统一 AI 网关（目的：凭证收敛 + 限流 + 审计）)
  - [4.2 Step 2：可观测性体系（目的：让 Agent 行为可追踪、可归因）](#4.2 Step 2：可观测性体系（目的：让 Agent 行为可追踪、可归因）)
  - [4.3 Step 3：护栏与权限模型（目的：Agent 自治等级的工程化落地）](#4.3 Step 3：护栏与权限模型（目的：Agent 自治等级的工程化落地）)
  - - [错误 vs 正确：护栏设计](#错误 vs 正确：护栏设计)
  - [4.4 Step 4：私有 Skill 商店（目的：把"个人会做"变成"组织能复用"）](#4.4 Step 4：私有 Skill 商店（目的：把"个人会做"变成"组织能复用"）)
  - - [Skill 商店的分发与治理](#Skill 商店的分发与治理)
  - [4.5 验证手段：用 DORA 五指标 + Agent 特异指标自检](#4.5 验证手段：用 DORA 五指标 + Agent 特异指标自检)
- 五、总结
- 下一篇预告
- 参考资料

AI Native 团队组建与基础设施搭建

前五篇 我们走完了"是什么---等级地图---协同进化---个人进化---落地路线图"这条认知链。

但凡是要落地的组织，最终都会撞上同一个具体问题：团队怎么搭？基础设施先建什么？

本篇是系列下篇"团队落地"的开篇，回答两个工程问题：人机配比怎么定、基础设施四件套怎么搭。

一、招了 5 个 AI 工程师，3 个月没产出

我们直接看一个真实场景。

某中型公司 CTO 听完一轮 AI 转型演讲，回来做了一个看起来很合理的决定：从大厂挖了 5 个 AI 工程师，单独成立"AI 创新组"，给最好的预算、最优先的需求，让他们把公司的核心业务"AI 化"。

三个月后复盘，结果让所有人沉默：

团队内部对"用 LangChain 还是裸调 API"争论了两周，没有结论
第一个上线的 RAG 问答 Demo，准确率在内部演示时只有 62%
没人能回答"这个 Agent 调一次多少钱""上线后怎么监控"
业务部门开始绕过这个组，自己偷偷用 ChatGPT 干活

这不是个别现象。Deloitte 2026 Tech Trends 报告给出一个很硬的数据：89% 的企业 AI Agent 试点没能进入生产 （Deloitte, 2026）。RAND Corporation 在 2025 年的追踪研究里给出的数字更冷峻------80.3% 的企业 AI 项目无法交付承诺的业务价值，其中 33.8% 在试点前就被放弃（RAND, 2025）。

第一性原理反问：AI Native 团队和传统研发团队，到底差在哪？

如果只是"招几个会用 AI 的人"，那 80% 的失败率从何而来？

差的地方比想象中要结构性得多。我们一层一层拆开看。

二、为什么 AI Native 团队不能照搬传统研发团队

2.1 康威定律在 AI 时代的复刻

康威定律（Conway's Law）说的是：任何设计系统的组织，其产出的系统结构都会复制该组织的沟通结构。

这条 1967 年提出的定律在 AI Native 时代不仅没有失效，反而被放大了。原因是------传统软件系统的"基本单元"是服务，而 AI Native 系统的基本单元是 Agent。Agent 是有"自主性"的，它对组织沟通结构的复刻，比对服务的复刻更敏感。

举一个我们在调研中看到的真实案例：

复制代码

传统组织结构：
  前端组 / 后端组 / 数据组 / 运维组
        ↓ 康威定律
系统架构：
  前端层 / 后端层 / 数据层 / 运维层（典型分层架构）

AI Native 组织结构：
  AI 平台组 / 业务 AI 组 / 数据组
        ↓ 康威定律
Agent 架构：
  平台 Agent / 业务 Agent / 数据 Agent
  各自有记忆、各自调工具、彼此通过 prompt 沟通

问题来了------当 Agent 之间需要跨域协作时，比如业务 Agent 要调数据 Agent 的能力，会触发什么样的协作成本？答案是完全复刻人类组的协作成本：排期、对接、口径不一致。Agent 没有自动绕开康威定律的特权。

ctaio.dev 在 2026 年发布的 AI Team Topology 分析里专门点出这个问题（ctaio.dev, 2026）：

"Conway's Law punishes every one of these mistakes by encoding bad org design directly into the AI system architecture."

翻译成工程语言 ：组织设计错了，Agent 系统架构会忠实地把错误固化下来，后续再改架构等于改组织。

2.2 麦肯锡 2.5 万 + 4 万：人机比例是诊断结果，不是 KPI

麦肯锡全球总裁 Bob Sternfels 在 2026 年 CES 上披露了一组被反复引用的数据（McKinsey/CES 2026, AI2Work 2026-04-20）：

指标	数值	来源
麦肯锡员工总数	6 万	CES 2026
其中人类	4 万	CES 2026
其中 AI Agent	2.5 万	CES 2026
18 个月前 Agent 数量	几千	CES 2026
QuantumBlack 团队规模	1700 人	McKinsey
AI 承担的业务比例	40%	QuantumBlack
节省工时	150 万小时/年	HBR IdeaCast
半年生成 PPT	250 万张	CES 2026

很多人看到这组数据的第一反应是："我们公司也要做到 1:1 的人机比例。"这是典型的把"诊断结果"当"KPI 目标"。

正确的读法 是：麦肯锡用了 18 个月，把 Agent 从几千个长到 2.5 万个，背后是 1700 人的 QuantumBlack 团队在做平台、Skill 库、治理。这个比例不是配置目标，是基础设施成熟后的自然产出。

反直觉点：人机比例不是"我们决定配多少 Agent"，而是"我们的基础设施能撑住多少 Agent"。

没有平台、Skill、护栏、可观测性的支撑，给团队配 10 个 Agent 都会变成 10 个新的故障源。

2.3 AI 团队拓扑的四种基本摆法

ctaio.dev 在 2026 年的分析里给出了 AI 团队的四种基本拓扑模型。我们直接借用这个框架，因为它比传统的"集中式/分布式"二分法工程化得多。

拓扑类型	结构	适用阶段	失败模式
CoE 集中式	一个 AI 团队服务全公司	0-2 个模型在产、<30 人初创	6 个月以上需求积压、变成瓶颈
嵌入式	AI 工程师进业务团队	AI 是 Feature 不是 Product	缺乏共享基础设施、重复造轮子
去中心化 + 平台	各业务团队自建 + 共享平台	多业务线、多模型在产	平台没人用、Shadow AI 泛滥
平台型	平台团队提供 AI 能力即服务	成熟期、规模化复制	平台脱离业务、需求错配

逐层解读这张表：

CoE 集中式是大多数公司的起点。一个 4 人的 ML 小组服务全公司，前 6 个月很顺畅。但 ctaio.dev 给了一个真实案例：某 200 人 SaaS 公司 18 个月后 5 个业务团队都要 AI，4 人小组变成 6 个月的瓶颈，被迫重组。
嵌入式 适合"AI 是 Feature"的场景，比如电商团队想给搜索加 RAG。但嵌入式的致命伤是每个业务团队都在自己搭基础设施，半年后公司里会有 5 套不同的向量库、3 套不同的 Eval 框架。
去中心化 + 平台 是 AI Native 的目标态，但前提是平台真的被用起来。Microsoft Work Trend Index 2026 给了一个数据：10% 的 AI 高能力用户被组织系统卡死 （Microsoft WTI 2026），他们绕过平台自己用 Shadow AI，是这个阶段的常见信号。
平台型是少数公司的终态，需要平台团队具备产品思维，否则就是"建好了平台没人用"。

选型建议 ：先选 CoE 起步、明确退出条件。CoE 的退出条件是"业务需求积压超过 2 个迭代"或"3 个以上业务团队同时要 AI 能力"。一旦触发，立刻向"去中心化 + 平台"演进。

不要试图一步到位到平台型------盖尔定律说复杂系统必须从简单系统演化而来。

2.4 三类新角色：被低估的"AI 时代新岗位"

Microsoft Work Trend Index 2026 提出了 Agentic 时代涌现的四类新角色（Microsoft WTI 2026）：

角色	中文	职责	必须具备的能力
Agent Supervisor	智能体主管	管理多个 Agent，定义 OKR 和奖励函数	系统思维、Agent 边界设计
Eval Owner	评估责任人	定义"成功"标准，搭建评估管线	数据科学、领域知识
Exception Handler	异常处理者	处理 Agent 搞不定的边界情况	领域专家、临场判断
HITL Reviewer	人在环路审核者	关键节点的人类审批	业务判断、风险嗅觉

这四类角色和传统研发团队的"产品经理 + 项目经理 + 测试 + 架构师"四件套，有重叠但绝不重合。

最容易被忽略的是 Eval Owner 。传统软件的"测试"是验证确定性逻辑------给定输入断言输出。AI Agent 的 Eval 完全不同------同一个输入可能产出不同的合理输出，需要的是概率化评估、回归测试集、漂移监控。这个角色缺位，团队就会陷入"我觉得 Agent 表现挺好"的幻觉。

Hubspot 在 2025 年的研究里指出（Hubspot, 2025）：Agent Trainer 和 Agent Manager 这两类新职位的招聘在过去两年增长了 150%+，薪资普遍超过 10 万美元。这说明市场已经在为这些角色定价。

光理解了"为什么不能照搬"还不够。下一步是回答两个具体问题：人机配比怎么定、岗位怎么设。

三、人机配比怎么定，岗位怎么设

3.1 三种配比模型：从 1:1 到 N:M

McKinsey 在 2025 年底发表的《The Agentic Organization》提出了一个被广泛引用的基准（McKinsey, 2025-12）：

一个由 2-5 个跨学科人类组成的团队，可以监督 50-100 个专业化 Agent 组成的"Agent 工厂"，端到端完成一个完整业务流程。

这个 2-5 : 50-100 的配比不是凭空来的，背后是 Agent 的自治等级（参考第 2 篇 L0-L5）和人类介入点的精确算计。我们把它扩展成三种典型配比模型：

配比模型	人类 : Agent	适用任务类型	典型场景
1:1 协作型	1 人 : 1 Agent	高创造性、强判断	架构设计、复杂客户对话
1:N 监督型	1 人 : 3-10 Agent	流程化、可枚举步骤	工单处理、报表生成、CI/CD 监督
N:M 编排型	2-5 人 : 50-100 Agent	端到端业务流	客户 Onboarding、产品发布

详细解读：

1:1 协作型 对应 Microsoft WTI 2026 四阶段中的 Author 模式（人类做主、AI 帮忙）。Agent 是放大器，不是替代者。复杂架构决策、关键客户对话属于这一类。
1:N 监督型 对应 Director 模式（人类给 Spec、Agent 执行）。一个工程师同时盯 5 个 PR Review Agent、3 个测试 Agent、2 个文档 Agent，是 Claude Code 团队的真实日常。
N:M 编排型 对应 Orchestrator 模式（人类设计系统、Agent 并行、人类只处理异常）。这是麦肯锡 2-5 : 50-100 的来源，也是 AI Native 团队的成熟态。

3.2 关键岗位设计：从"全栈工程师"到"复合型工程师"

麦肯锡 2026 年的招聘数据揭示了一个明显的变化："复合型工程师"岗位的录取率比传统咨询顾问高 47% （McKinsey, 2026-01）。这类岗位的要求是：

同时具备商业分析能力、数据科学素养和 AI 系统开发经验。

这个描述可以拆成三层：

复制代码

复合型工程师能力栈
   ↓
业务层：理解业务目标、能拆解 KPI、能定义 Agent 的成功标准
   ↓
数据层：熟悉数据流、知道 RAG 的边界、能设计 Eval
   ↓
工程层：能写生产级代码、能调 Agent 框架、能做可观测性

麦肯锡在 2026 年 CES 的访谈里专门提到：学历背景（哈佛、耶鲁）的权重在下降，实际产出（GitHub 项目、用 AI 解决问题的能力）成为更重要的考核指标 。他们甚至开始让候选人在终面使用内部 AI 工具 Lilli 完成一个咨询案例，考的不是会不会用 AI，而是会不会"指挥" AI。

3.3 错误 vs 正确：岗位描述怎么写

我们直接看一个对比：

yaml 复制代码

# ❌ 错误：把 AI 工程师当传统岗位招
岗位：AI 工程师
职责：负责公司 AI 平台的开发和维护
要求：熟悉 Python、LangChain、向量数据库

# ✅ 正确：按 AI Native 团队角色招
岗位：Agent 平台工程师（Eval Owner 角色）
职责：
  - 设计和实现 Agent 评估管线（覆盖 5 类指标：工具调用准确率、
    任务完成率、Token 成本、延迟、用户满意度）
  - 维护版本化的回归测试集（500-1500 条/业务域）
  - 在 PR 流程中接入 Eval Gate，未通过的变更阻断发布
要求：
  - 熟悉 LLM Eval 框架（DeepEval / FutureAGI / Braintrust 至少一种）
  - 理解 OTel GenAI 语义规范
  - 有生产级 Agent 系统的可观测性经验

关键差异：

错误版本描述的是**"会什么工具"**------这种岗位招来的人，会写 LangChain 但不知道为什么 Eval 要分层。
正确版本描述的是**"承担什么责任、用什么手段、产出什么"**------这种岗位的人能直接对 Agent 系统的产出质量负责。

3.4 选型理由：为什么 2-5 人 + 50-100 Agent 是起点

回到麦肯锡的 2-5 : 50-100 这个配比，背后的逻辑是什么？

第一，认知带宽限制。一个人同时监督的 Agent 数量上限，取决于异常处理的频次。如果每个 Agent 每天 5 次异常、每次需要 5 分钟人类介入，10 个 Agent 就是每天 4 小时的异常处理工作量，已经接近认知带宽上限。

第二，Skill 复用效率 。50-100 个 Agent 的规模，才能撑起一个有意义的私有 Skill 商店。Anthropic 内部活跃使用的 Skill 有数百个（Anthropic, 2026-06），这是规模化复用的前提。

第三，组织协同成本。2-5 人是人类团队协同的"甜区"------Amazon 的"两个披萨团队"原则。超过这个规模，内部沟通成本会指数级上升。

落地建议 ：如果团队规模小于 20 人，先从 1:3 配比起步（1 个工程师监督 3 个 Agent），验证基础设施和协作流程，再逐步扩到 1:10。不要一上来就追求麦肯锡的 2-5 : 50-100。

人配比和岗位定下来，下一步是基础设施。这是 80% 失败的 AI 项目最常被跳过的环节。

四、基础设施四件套：从 AI 网关到 Skill 商店

FutureAGI 在 2026 年 2 月发布的 LLM Deployment Best Practices 给出了一个六层部署栈（FutureAGI, 2026-02-26）。我们把它工程化、本土化，收敛成团队起步必须先搭的"四件套"。

4.1 Step 1：统一 AI 网关（目的：凭证收敛 + 限流 + 审计）

为什么是第一步：没有统一网关，每个工程师自己持 LLM API Key 调用，公司根本不知道一个月烧了多少钱、调了哪些模型、出过什么错。

Anthropic 在 Claude Code 的工程博客里把这一层叫 AI 网关平面 （51CTO, 2026-06-23），收敛三类资源：

复制代码

AI 网关收敛三类资源
   ↓
LLM 凭证：OpenAI / Anthropic / Azure / 自托管，统一鉴权
   ↓
MCP 服务：内部系统接口转 MCP，Agent 标准化调用
   ↓
Skill 模板：版本化、权限分级、可追溯

一个最小可用的 AI 网关需要具备：

能力	必需	实现
凭证管理	✅	Vault / AWS Secrets Manager
路由策略	✅	按模型、按成本、按业务线
限流熔断	✅	Token bucket + 熔断器
调用审计	✅	全量日志，留存 90 天
缓存	可选	语义缓存降本
Fallback	可选	主备模型切换

详细解读 ：审计不是"为了合规"，是为了回答两个工程问题------"这个月为什么花了 8 万美元 token 费"和"昨天那笔订单为什么 Agent 给了错误的折扣"。没有审计日志，这两个问题永远答不上来。

4.2 Step 2：可观测性体系（目的：让 Agent 行为可追踪、可归因）

LLM 系统的可观测性和传统软件完全不同。LaunchDarkly 在 2026 年 5 月的 LLM Observability 指南里给了一个核心定义（LaunchDarkly, 2026-05-11）：

LLM 可观测性关注的是"模型怎么思考、怎么响应、怎么演进"，而不是传统的"CPU 负载、内存使用"。

Elastic 在 2026 年的 Gartner Magic Quadrant 报告里被列为 Leader，他们的 LLM Observability 方案覆盖了五层监控：

监控层	关注点	典型指标
性能	延迟、吞吐	p50 / p95 / p99 延迟、QPS
成本	Token 消耗	按模型、按业务线、按用户
安全	敏感数据、Prompt 注入	PII 泄露、越狱尝试
质量	幻觉、上下文接地	Faithfulness、Groundedness
行为	工具调用、轨迹	Tool Selection Accuracy、Step Count

最容易跳过的是质量层 。性能和成本是 SRE 的本能，安全有合规驱动，但质量监控必须主动建设 ，因为它不是阈值告警能解决的。Galileo 在 2026 年的研究里指出（Galileo, 2026-05-01）：

生产环境 LLM 的失败率在 5%-30% 之间波动，最先进的模型仍然在 15%-20% 的回答中产生幻觉。

这意味着没有质量监控，团队的 Agent 系统会在用户侧静默退化，而团队毫不知情。

4.3 Step 3：护栏与权限模型（目的：Agent 自治等级的工程化落地）

这一步直接对应第 2 篇讲的 L0-L5 自治等级。但抽象的等级要落到工程上，需要一个具体的权限模型。Anthropic 在 Claude Code 上做了一次教科书级的示范。

Claude Code 在 2026 年 7 月 3 日的 v2.1.200 版本里做了一个看似微小但影响深远的变更（c114pro, 2026-07）：

将默认权限模式从 Auto 改为 Manual。

这次变更背后是 Anthropic 自己的工程数据：用户对权限提示的通过率是 93% ------典型的"approval fatigue"（审批疲劳）。这个数字说明，让人类对每个 Agent 动作做实时审批是没有意义的，人类必须有，但不能在每个动作上。

Claude Code 最终落地的权限模型有 5 档：

模式	行为	适用场景	风险等级
Manual	每个动作都需人类确认	学习阶段、敏感操作	最低
acceptEdits	文件编辑自动批准，命令仍需确认	日常开发	低
Plan	只读、只规划、不执行	复杂任务前置规划	无
Auto	Sonnet 4.6 分类器评估每个动作	受控生产环境	中
bypassPermissions	完全跳过权限（`--dangerously-skip-permissions`）	仅 CI/CD 沙盒	最高

关键解读 ：Auto 模式的分类器有 0.4% 的误报率 和 17% 的漏报率 （c114pro, 2026-07）。漏报率 17% 意味着------每 6 个应该被拦截的危险动作，有 1 个会溜过去。这就是为什么 bypassPermissions 模式只能用在隔离容器里。

落地建议 ：团队起步阶段，所有生产环境的 Agent 都用 Manual 模式。当某类操作的误报率连续 2 周低于 5%，再单独把这类操作升级到 Auto 模式。永远不要在生产环境用 bypassPermissions。

错误 vs 正确：护栏设计

yaml 复制代码

# ❌ 错误：粗粒度 allow-all
permissions:
  allow: ["Bash", "Write", "Read"]
  deny: []

# ✅ 正确：细粒度参数级控制（Claude Code v2.1.178 语法）
permissions:
  allow:
    - "Read"
    - "Glob"
    - "Grep"
    - "Bash(npm run test)"
    - "Bash(git status)"
    - "Bash(git diff)"
  deny:
    - "Bash(rm -rf *)"
    - "Bash(git push --force*)"
    - "Bash(curl * | bash)"
    - "Read(./.env*)"
    - "Read(./**/secrets/*)"

关键差异 ：错误版本等于把 root 权限交给 Agent；正确版本把权限收敛到具体命令和具体路径，敏感文件用 Read(./.env*) 显式 deny。这套语法是 Claude Code 在 v2.1.178 版本引入的（clauder-navi, 2026-06-17），让权限从"工具级"细化到"参数级"。

4.4 Step 4：私有 Skill 商店（目的：把"个人会做"变成"组织能复用"）

这是基础设施四件套里最容易被低估 的一件。腾讯云开发者社区在 2026 年 7 月的文章里给出了一个准确的定位（腾讯云, 2026-07-13）：

知识库解决"问到哪里找答案"，Skill 解决"拿到任务以后怎么执行"。

Skill 不是文档，是可执行的能力包 。Anthropic 在 Claude Code 的官方博客里反复强调一个被广泛误解的点（Anthropic, 2026-06-03）：

"A common misconception we hear about skills is that they are 'just markdown files.' They're actually folders that can include scripts, assets, data, etc."

一个标准 Skill 是一个文件夹，至少包含 7 个组成部分：

复制代码

my-skill/
├── SKILL.md              # 入口：何时用我 + 操作指引 + 坑点
├── frontmatter          # name + description（触发条件）
├── references/          # 参考资料（细节文档）
├── scripts/             # 可执行脚本
├── assets/              # 输出模板
├── config.json          # 首次使用配置
└── data/                # 持久化数据（${CLAUDE_PLUGIN_DATA}）

Skill 正文的黄金法则 ：只写 Agent 推断不出来的，删掉它本来就会的。Anthropic 给的最强信号是 Gotchas（坑点清单） ------比如"subscriptions 表是只追加不修改的，要找的记录是 version 最大的那条，不是 created_at 最新的那条"。这种信息 Agent 靠读代码永远推断不出来。

Skill 商店的分发与治理

Anthropic 内部的玩法是自然演化（Anthropic, 2026-06-03）：

复制代码

Step 1: 工程师写了个 Skill，扔进沙盒目录，Slack 里吆喝一声
Step 2: 用的人多了、口碑起来了
Step 3: 作者提 PR，从沙盒挪进正式 marketplace
Step 4: PreToolUse Hook 监听调用，沉淀使用数据
Step 5: 调用量大的 Skill 重点维护，触发不足的回去改 description

关键点 ：审批环节越重，愿意分享的人越少。Anthropic 没有"中心化审批委员会"。门槛低到"扔进沙盒就行"，几百个 Skill 才能攒起来。

4.5 验证手段：用 DORA 五指标 + Agent 特异指标自检

基础设施搭完，怎么知道搭得对不对？传统研发团队有 DORA 五指标（DORA, 2024-2026）：

指标	含义	AI Native 团队怎么用
Deployment Frequency	部署频率	每周至少 2 次 Agent 迭代
Change Lead Time	变更前置时间	Prompt/Skill 变更 < 24 小时上线
MTTR	平均恢复时间	Agent 故障 < 30 分钟自愈
Change Failure Rate	变更失败率	Agent 变更回滚率 < 10%
Rework Rate	返工率（2024 新增）	< 15%

Thoughtworks 在 2026 年 4 月的 Technology Radar 里专门指出（Thoughtworks, 2026-04-15）：

在 AI 辅助开发时代，DORA 指标比以往更重要。用 AI 生成的代码行数来衡量生产力是误导性的------真正的改进必须体现在交付流和稳定性上。

但 DORA 五指标只覆盖了"软件交付"维度，对 Agent 系统还需要补充三类特异指标：

维度	指标	目标值
工具调用准确率	Tool Selection Accuracy	> 90%
任务完成率	Task Completion Rate	> 85%
Token 成本	Cost per Task	按业务域定基线
轨迹合理性	Step Count / Reasoning Coherence	按任务复杂度
漂移监控	Embedding / Output Drift	周对比 < 5%

检查清单 ：DORA 五指标 + 上述五类 Agent 指标，每周出一次报告。如果连续 2 周某指标低于目标值，立即停止新增 Agent，回头修基础设施。

五、总结

本篇是 AI 原生组织系列"下篇：团队落地"的开篇，回答了两个具体工程问题。

核心结论：

康威定律在 AI 时代被放大 ：Agent 系统会忠实复刻组织沟通结构。组织设计错了，Agent 架构会把错误固化。先设计组织，再设计系统。
人机比例是诊断结果，不是 KPI：麦肯锡的 2.5 万 + 4 万不是配置目标，是基础设施成熟后的自然产出。给团队配 10 个 Agent 但没有平台、Skill、护栏、可观测性，等于 10 个新的故障源。
三类新角色必须有人担任：Agent Supervisor、Eval Owner、Exception Handler。Eval Owner 是最容易被忽略、但最致命的角色。
基础设施四件套必须先建 ：AI 网关（凭证收敛）→ 可观测性（行为可追踪）→ 护栏权限（自治可控）→ Skill 商店（能力可复用）。这个顺序不能反。
DORA 五指标 + Agent 特异指标 是基础设施健康度的体检表。连续 2 周低于目标值就停止扩 Agent，回去修基础设施。

适用边界：

✅ 适合：已经有 3+ 个 AI 用例在跑、但缺乏统一基础设施的中型团队。
⚠️ 慎用：团队 < 10 人的早期阶段------先聚焦 1-2 个高价值用例，不要一上来就建四件套。
❌ 不适合：还没想清楚"AI 解决什么业务问题"的团队------基础设施不创造业务价值，只是放大器。

下一篇预告

本篇讲的是"团队怎么搭、基础设施怎么建"。但基础设施搭好了，团队日常怎么"跑起来"？

下一篇：【AI原生组织】7-AI Native团队运作机制与度量进化

站会、代码审查、PR 流程在人机混编下怎么改？
Microsoft WTI 四阶段协作模式（Author / Editor / Director / Orchestrator）怎么落地？
从 L1 个人尝鲜到 L5 智能化运营，演进路径上的关键拐点在哪？
团队度量体系怎么从 DORA 走到 Agent-aware？

我们下一篇见。

参考资料

本文属于「AI原生组织」系列文章第 6 篇

AI原生组织系列：

上篇·认知

下篇·落地

当前文章（本文）
7-AI Native团队运作机制与度量进化