第 32 章 团队与产品：把 Agent 变成团队资产，而不是个人玩具

从个人玩具到团队资产

前 31 章讲的都是"Agent 怎么工作"。最后一章回答一个更宏观的问题：Agent 怎么在一个团队里、一个产品里真正落地？

很多团队的情况是：个别工程师用 Agent 用得风生水起，但整个团队的 Agent 行为各不相同、配置各写各的；Agent 的能力没有沉淀成团队资产；代码库还是按人优化的，Agent 干起活来磕磕绊绊。这一章讲四个模式，把 Agent 从"个人玩具"变成"团队资产"：

1. Team-Shared Agent Configuration（团队共享配置）：配置进版本控制，全队一致。
2. Factory over Assistant（工厂而非助手）：从"看着 Agent 干活"到"派一群 Agent 干活"。
3. Codebase Optimization for Agents（面向 Agent 的代码库优化）：代码库先为 Agent 优化，再为人优化。
4. Latent Demand Product Discovery（需求发现）：用可 hack 的产品找真实需求。

模式一：团队共享配置（Team-Shared Agent Configuration as Code）

问题

当每个工程师独立配置自己的 AI Agent 时：

• 行为不一致：Agent 对不同的团队成员表现不一样。
• 权限摩擦：人人都被同一批安全命令反复要权限。
• 重复劳动：每个人解决同样的配置问题。
• 知识孤岛：好配置不会在团队里传播。
• 入职开销：新成员从零开始。
• 安全缺口：没有"Agent 能碰什么、不能碰什么"的标准化规则。

方案

把 Agent 配置作为仓库的一部分检入版本控制。 把 settings.json（或等价物）当代码对待，和你的项目一起可审查、可共享、可版本化。

关键配置元素：

1. 预允许命令：不需要权限提示的工具。
2. 阻止的文件/目录：Agent 绝不能碰的东西。
3. 默认子 Agent：团队标准的专门 Agent。
4. 斜杠命令：大家都能用的共享工作流。
5. 钩子（Hooks）：标准化的自动化触发。

// .claude/settings.json（检入仓库）
{
  "permissions": {
    "pre_allowed": [
      "git add",
      "git commit",
      "git push",
      "npm test",
      "npm run lint"
    ],
    "blocked_paths": [
      ".env",
      "secrets/",
      "*.key",
      "credentials.json"
    ]
  },
  "subagents": {
    "security-review": "./agents/security.md",
    "migration-helper": "./agents/migration.md"
  },
  "hooks": {
    "pre_commit": "./hooks/run_tests.sh"
  }
}

怎么用

实施步骤：

1. 建共享配置文件：从所有成员都需要的公共设置开始，大家都会跑的命令（git、测试运行器、linter）、谁都不该改的敏感路径、标准工作流。
2. 版本控制它：git add + git commit + git push。
3. 团队采用：新成员 clone 仓库就自动拿到配置。
4. 支持本地覆盖：用 gitignored 的本地文件（.claude/settings.local.json）做个人定制，多数平台做分层合并，本地覆盖优先。
5. 团队一起迭代：PR 能更新 Agent 配置；代码审查同样适用于 Agent 设置；改动通过正常 git pull 传播。

企业部署里观察到的收益（Boris Cherny）：大规模部署 Claude Code 的公司都有检入代码库的 settings.json，用来预允许某些命令免去每次权限提示、阻止某些命令，然后分享给整个团队。

最佳实践： 本地覆盖单独放（gitignored）；用 JSON Schema 验证在运行前抓配置错误；文档说明为什么预允许/阻止某些东西；每季度审计配置（工具和威胁在演进）；从最小开始渐进采用；绝不提交凭据，用环境变量或本地配置。

取舍

• 好处：团队体验一致，每个人的 Agent 行为一样；入职更快，新成员立即继承团队知识；减少摩擦，预允许命令消掉重复提示；安全标准化，敏感文件有统一规则；协作改进，团队用 PR 一起改进配置；可审计，版本历史显示配置为什么改。
• 代价：个人灵活性降低；个人偏好和团队标准可能冲突；配置文件会变复杂；需要给个人定制留逃生口；要确保提交的配置里没有凭据。

模式二：工厂而非助手（Factory over Assistant）

问题

"助手"模式，在侧边栏里和 Agent 一对一工作、看着它干活、来回 ping-pong，限制了生产力和可扩展性。随着模型更自主、更能干，人反而成了瓶颈，因为人就是反馈回路。在侧边栏里看着 Agent 干活，一次只能跑一个。

方案

从"助手模式"转向"工厂模式"：派发多个并行工作的自主 Agent，定期查看它们，把时间花在更高级的编排上，而不是当反馈回路。

工厂心态：

• 派多个 Agent 去干不同任务。
• 30-60 分钟后定期查看。
• 专注搭自动化反馈回路（测试、构建、技能）。
• 为并行和自主优化。

助手模式为什么在消亡：

1. 限制并行化：看着 Agent 干活时，实际只能有效跑一个。
2. 人当拐杖：你成了反馈回路，本应搭自动化回路。
3. 优化错了方向：侧边栏 UX 优化的是"看"，不是"自主干活"。
4. 拖后腿：慢模型在侧边栏好用，好模型自主干活更好。

助手模式（旧）: 人 ←→ 侧边栏 ping-pong → Agent → 一次一个任务 → 结果
工厂模式（新）: 人 → 派任务 → Agent1 / Agent2 / Agent3（并行）
                → 自动化反馈回路 → 结果
                → 定期查看 → 整合

演进：

阶段	模型	人的角色	Agent 行为
过去	助手	看着一切、提供反馈	频繁查看、交互
现在	混合	搭自动化回路	交互 + 自主混合
未来	工厂	编排和审查	完全自主、最少人接触

关键洞见： 像 GPT-5.2 这样能自主干活 45+ 分钟的模型，在侧边栏里看着它干活是浪费。你应该能派 10 个这样的 Agent，然后回头一起检查。

学术支持： 多 Agent 研究（OpenDevin、AutoGen、CAMEL）验证了并行自主执行优于单助手交互。

怎么用

从助手到工厂的转型：

1. 转移时间投入：

# 助手模式（旧）
time_distribution:
  watching_agent_work: 80%     # 看着 Agent 干活
  actual_development: 20%      # 实际开发

# 工厂模式（新）
time_distribution:
  setting_up_automated_loops: 30%   # 搭自动化回路
  spawning_and_orchestrating: 20%   # 派发和编排
  review_and_integration: 50%       # 审查和整合

2. 建自动化反馈回路： 别自己当反馈回路，搭：Agent 自动跑的测试命令、验证正确性的构建命令、封装常见操作的技能、Agent 用的 linter 和格式化器。

3. 每种模式用合适的模型： 交互模式用"爱扣扳机"的模型（Opus）做快任务；工厂模式用"懒"的研究型模型（GPT-5.2）做自主活。

4. 拥抱异步工作流：

# 旧工作流（助手）
user → agent → user → agent → user → agent → result

# 新工作流（工厂）
user → spawn(agent1) + spawn(agent2) + spawn(agent3)
→ 干别的
→ 回头检查
→ 整合结果

AMP 的实战例子： AMP 正在砍掉他们的 VS Code 扩展，因为他们相信：最前沿的 1% 开发者只需要在编辑器里完成 20% 的工作，他们想把那个数字降到 10% 或 1%。侧边栏在前沿开发里已死，工厂模式能更有效利用自主模型。

其它生产实现： Anthropic Claude Code 内部用户报告，用 map-reduce 跨 10+ 并行 Agent 做框架迁移提速 10 倍以上；GitHub Agentic Workflows 让 Agent 在 CI/CD 里跑，分支对任务隔离；Cursor Background Agent 做云端自主开发，自动建 PR。

取舍

• 好处：大规模并行化，同时跑多个 Agent；人的时间用得更好，专注编排不是观看；随模型能力扩展，更自主的模型 = 更有效的工厂；延迟降低，不用等 Agent 每步完成；吞吐更高，多个任务并行完成。
• 代价：失去实时控制，没法实时引导 Agent；反馈延迟，可能要 30-60 分钟才看到问题；搭建开销，要稳健的自动化反馈回路；更难调试，出问题时过程可见性更少；工具要求，需要好的监控和查看机制。

工厂模式不适用时： 探索性工作（你还不知道想要什么）；需要频繁人工引导的任务；没被技能/文档捕获的复杂领域知识；快速迭代时交互反馈更快。

"最后 20%"原则： 工厂模式不消灭编辑器，它把编辑器缩减到最后的整合工作。"最想领先的 1% 开发者只需要在编辑器里做最后 20% 的工作，我们觉得能把它降到 10% 或 1%。"

模式三：面向 Agent 的代码库优化（Codebase Optimization for Agents）

问题

给代码库引入 AI Agent 时，自然倾向是保留人类开发者体验（DX）。但这限制了 Agent 的效果，因为代码库还是按人优化的，不是按这些越来越多自主干活的 AI 工人优化的。

一个相关问题：再好的模型，没有清晰的反馈回路也会挣扎。 当 Agent 无法验证自己的改动是否有效时，它失败不是因为能力限制，而是因为代码库没有"焊"到 Agent 身上。

方案

先为 Agent 优化代码库，再为人优化。 接受工具、工作流、甚至编辑器体验可能为人退化，以换取 Agent 表现的显著提升。

反直觉的洞见： 一旦你接受 Agent 优化的工作流，你本来也会更少用面向人的工具（比如 VS Code），所以让它们退化没那么要紧。

AMP 的真实例子： 团队做了 Zveltch（Zig 写的拼写检查）让拼写检查对 Agent 快。这实际上让人类的 VS Code 体验更差了。他们面临艰难抉择：保人类 DX 还是为 Agent 优化？他们最终选了为 Agent 优化，带来"雪球效应"：

为 Agent 优化 → Agent 表现更好 → 人更多用 Agent → 人更少用编辑器
→ 编辑器 DX 更不重要 → 更多动力为 Agent 优化 →（循环）

核心原则：愿意放弃传统开发者工具的执念。

"把 Agent 焊到代码库"： "焊"的隐喻是建立紧密的自动化反馈回路，让 Agent 能：自动验证改动有效、拿到成功/失败的清晰信号、无需人工干预地迭代。

实战例子：

• 带截图标志的终端模拟器：加 --capture-to 标志，Agent 能截图验证渲染修复。
• CLI 纯数据输出：建新子命令输出原始数据（无 UI 格式化），Agent 能程序化解析结果。
• 测试命令：单命令测试执行（pnpm test）带缓存结果。

怎么用

Agent 优化可能和人类优化不同的领域：

1. 命令接口

# 人优化 CLI
- 交互提示
- 彩色输出
- 进度条
- 帮助文本和菜单

# Agent 优化 CLI
- 单命令接口（如 pnpm test）
- 机器可读输出
- 缓存结果
- 最少啰嗦输出

已有先例： 现代 CLI 普遍支持 JSON 输出供 Agent 消费：GitHub CLI（--json）、kubectl（-o json）、AWS CLI（--output json）、Terraform（output -json）。

2. 文档和知识

# 人优化文档
- 叙事性解释
- 教程和指南
- 截图和图表

# Agent 优化文档
- 结构化参考
- 代码示例
- 清晰的输入/输出格式
- 封装工作流的技能

3. 测试和验证

# 人优化测试
- 描述性测试名
- 有用的错误消息
- 调试输出

# Agent 优化测试
- 快速执行
- 缓存结果
- 清晰的通过/失败信号
- 自动化修复建议

4. 技能和能力

最有影响力的优化：建封装你代码库独特操作的技能。AMP 的例子：GCloud 技能做日志分析（替代 web 仪表盘）、BigQuery 技能做数据查询、发布管理技能、部署技能。

5. AGENTS.md 文件

建 AGENTS.md 或类似文档，说明：怎么测试应用、怎么认证、用什么反馈机制、自动化交互的特殊考虑。（这个仓库的 AGENTS.md 就是干这个的。）

"Agent 原生代码库"清单（2026 版 Joel 测试）：

Joel 测试（2004）	Agent 测试（2026）
第一天能交付东西吗？	Agent 10 分钟能交付东西吗？
单命令开发环境搭建	单命令测试/验证循环
容易推到生产	Agent 容易部署和验证
容易审查代码	Agent 容易自我验证
CI 跑测试	CI 提供机器可读反馈
好文档	带工作流指令的 AGENTS.md

决策框架：

问题	是 →	否 →
人每天用这个吗？	考虑混合	为 Agent 优化
Agent 会比人多用 10 倍吗？	为 Agent 优化	保留人类 DX
这是核心开发者工作流吗？	混合方案	Agent 优先
这需要人类判断吗？	人优先	Agent 优先

取舍

• 好处：Agent 表现大幅提升，更快更可靠；加速向 Agent 优先工作流转型；面向未来，为 AI 自主性增加做好准备；复利改进，更好 Agent → 更多使用 → 更多投入 → 更好 Agent。
• 代价：人类 DX 退化，传统工作流可能变差；团队抵触，开发者可能抵制"更差"的工具；混合团队挑战，有些成员不那么用 Agent；锁定风险，重投 Agent 特定模式。

心理转变： "Agent 不是这些复杂构建工具和可复现构建会赢的证明。它们其实很擅长用笨工具，你不需要重型的复杂工具。" Agent 用简单、可靠、笨的工具表现出色。为人设计的复杂工具常常加不必要的开销。

什么时候为 Agent 优化： Agent 会用某个工作流超过人的 10 倍；工作流可自动化、定义清晰；速度比用户体验重要；你承诺 Agent 优先开发。

什么时候保留人类 DX： 工作流需要人类创造力或判断；人是主要用户（Agent 很少碰）；工作流是探索性的、规格不清；团队没有完全接受 Agent 优先方法。

模式四：需求发现（Latent Demand Product Discovery）

问题

做 Agent 产品时，很难在投入大量工程之前知道哪些功能会有真正的产品市场契合。传统功能开发依赖用户访谈和问卷，但这些可能揭示不了用户实际上会怎么改造工具来满足需求。

方案

把产品建得刻意"可 hack"、可扩展，然后观察高级用户怎么"滥用"或重新利用功能做计划外的用途。这揭示潜在需求，通过行为而不是口头偏好展示的真实用户需求。识别出这些模式后，把它们产品化给所有用户。

关键原则：

1. 做扩展点：提供用户能定制的钩子、插件、斜杠命令、配置文件。
2. 监控创意使用：盯用户把功能 hack 到超出原始意图的模式。
3. 量化信号：衡量有多少用户在干"计划外"的行为。
4. 产品化已验证的需求：为表现出强采用的行为建正经功能。

怎么用

实施策略：

• 核心功能带清晰的扩展 API。
• 让高级用户容易配置和定制。
• 监控分析和用户反馈，找意外使用模式。
• 找多个独立用户都发现的那些行为。
• 优先为高频"hack"建功能。

来自访谈的具体例子：

1. Facebook Dating：分析显示 60% 的资料浏览发生在异性非好友之间，清晰的约会行为，于是推出 Facebook Dating。
2. Facebook Marketplace：40% 的 Facebook 群组帖是买卖交易，用户把群组当市场，于是推出专门的 Marketplace 产品。
3. Claude Code 的 Slack 钩子：用户想要 Claude 要权限时收到 Slack 通知，于是建了 hooks 系统，用户自己实现。

取舍

• 好处：用行为而不是臆测验证真实需求；降低建没人要的功能的风险；让高级用户替你创新；使用和开发之间建立紧反馈回路；功能自带概念验证。
• 代价：前期要建可扩展性基础设施；等信号期间可能推迟上线"显而易见"的功能；高级用户行为不一定代表主流需求；要分析和监控系统检测模式；每个 hack 都做成产品会导致功能膨胀。

四个模式怎么选

场景	推荐模式
团队 Agent 行为不一致	团队共享配置
一个人盯一个 Agent，产能上不去	工厂而非助手
代码库还是按人优化的	面向 Agent 的代码库优化
做 Agent 产品，不知道做什么功能	需求发现

四个模式是团队与产品的四个维度：共享配置让 Agent 成为团队标准，工厂模式把个人产能变成团队产能，代码库优化让 Agent 在团队代码库里有反馈回路，需求发现让产品从用户行为里找方向。团队、产能、代码库、产品，四个都到位，Agent 才真正落地。

实践清单

• 把 Agent 配置（预允许命令、阻止路径、子 Agent、钩子）检入版本控制
• 本地覆盖用 gitignored 文件，绝不提交凭据，季度审计配置
• 从助手模式转向工厂模式：派多个 Agent 并行，搭自动化反馈回路
• 时间从"看着 Agent 干活"转移到"搭回路 + 编排 + 审查整合"
• 交互任务用"爱扣扳机"模型，自主任务用"懒"研究型模型
• 代码库先为 Agent 优化：单命令验证、机器可读输出、缓存结果
• 建封装代码库独特操作的技能，写 AGENTS.md 说明测试/认证/反馈机制
• 决策问三问：Agent 会比人多用 10 倍吗？需要人类判断吗？是核心工作流吗？
• 产品做可 hack 的扩展点，观察高级用户滥用，把强采用行为产品化

本章小结

• 团队共享配置：配置即代码，全队一致、入职快、安全有标准。
• 工厂而非助手：派一群 Agent 并行干活，人当编排者不当反馈回路。
• 面向 Agent 的代码库优化：先为 Agent 优化再为人优化，用反馈回路把 Agent"焊"到代码库。
• 需求发现：可 hack 的产品 + 观察用户滥用，用行为找真实需求。

到这里，八个部分、32 章就全部讲完了。让我们把整本书串起来看一眼：

全书回顾：从最小可行 Agent 到生产级 Agent 系统

第一部分（1-4 章） 建了基础语言：规划-执行-观察、反思闭环、委派，让第一个 Agent 跑起来。

第二部分（5-9 章） 把上下文当操作系统治理：预算、压缩、最小化、记忆、学习沉淀，省 token、管好上下文。

第三部分（10-13 章） 让 Agent 动手：接口设计、工具发现、执行环境、代码执行与沙箱。

第四部分（14-18 章） 让它可靠：结构化输出、验证循环、评测基建、可观测性、韧性工程。

第五部分（19-23 章） 让它安全：威胁模型、控制流隔离、权限审批、凭据出口、多智能体信任。

第六部分（24-27 章） 让它进化：反馈信号、评测驱动改进、强化学习、复合式进化。

第七部分（28-30 章） 规模化到多智能体：协调、模型路由、推理搜索结构。

第八部分（31-32 章） 落地最后一公里：控制谱系、团队与产品。

三条暗线始终贯穿：确定性光谱（哪里让模型决定、哪里用代码锁死）、上下文经济（token 是钱）、信任与放权阶梯（从步步审批到完全自主）。

回到开头那个问题：为什么教程里的 Agent 跑得很好，一上生产就翻车？因为生产要的不是一个聪明模型，而是一个工程系统。现在你手里有 80 个模式，知道每个环节该用什么、代价是什么、证据在哪。剩下的，就是在真实系统里把它们组合起来，取舍出属于你的那套架构。祝你的 Agent 们在生产里活得好。