本阶段的核心命题 从"单个功能能跑"走向"可部署、可运营、可扩展的 Agent 平台或 Harness 产品"。
范围声明：Pi Agent 桌面端的完整产品战略与商业模式画布不在本阶段做，统一收敛到 阶段 14 综合项目 A。本阶段只建立判断框架。
| Prototype | MVP | Production | |
|---|---|---|---|
| 目标 | 验证"能不能做" | 验证"有没有人用" | 让它可靠地运转 |
| 成功率要求 | 演示能过 | 主路径能过 | 长尾也要有兜底 |
| 评测 | 无 | 少量用例 | 回归集 + 准入门槛（阶段 10） |
| 权限与安全 | 无 | 关键动作确认 | 完整授权矩阵 + 审计（阶段 11） |
| 可观测性 | 打印日志 | 基础 trace | 成本归因 + 趋势 + 告警 |
| 会话/恢复 | 无 | 简单存储 | 持久执行 + 回滚（阶段 7） |
| 失败表达 | 报错 | 有提示 | 四段式 + 部分成功（阶段 12） |
| 工作量占比 | ~10% | ~30% | ~60% |
"最后 60%"的真相 Agent 产品最反直觉的一点：Demo 到生产的工作量，远大于从零到 Demo。 这条差距几乎全部落在阶段 7、10、11、12 这四块。
这也解释了 2026 年的行业现象：很多企业报告"已在生产环境运行 Agent"，但真正持续产生价值的比例低得多——差距就在这 60% 上。做规划时，把 Demo 的排期乘以 3 到 5 倍，通常比"再优化优化提示词"更接近真相。
| 维度 | 倾向自建 | 倾向采购 |
|---|---|---|
| 差异化 | 这是你的核心竞争力 | 通用能力 |
| 数据边界 | 数据不能出域 | 可托管 |
| 迭代速度 | 需要深度定制 | 标准场景，越快越好 |
| 长期成本 | 规模大，自建摊薄 | 规模小，采购更便宜 |
混合是常态：内核用开源/商用 Harness，工具面、评测集、授权矩阵、领域 Skill 自建——因为这四项才是护城河（见第六节）。
| 选择 | 关键问题 |
|---|---|
| 开源 Harness | 谁维护？上游断更怎么办？我们改了以后还能跟上游同步吗？ |
| 闭源/托管 | 数据出域吗？可观测性够吗？涨价怎么办？ |
| 本地部署 | 分发与更新成本（阶段 7）、跨平台成本（Windows 系数） |
| 云端 | 访问用户本地环境的能力受限；合规路径 |
一旦从"一个 Agent"变成"一个 Agent 平台"，这六件事必须补齐：
| # | 事项 | 关键问题 |
|---|---|---|
| 1 | 租户与身份 | 数据隔离、权限透传（不要用共享服务账号，见阶段 11） |
| 2 | 计费与配额 | 按什么计量？谁的额度？超了怎么办？ |
| 3 | 限流 | 单用户、单租户、全局三层 |
| 4 | 配置与版本管理 | 提示词、工具、Skill 各自的版本与灰度 |
| 5 | 模型升级与兼容 | 换模型要重跑哪些评测？回滚路径是什么？ |
| 6 | 可观测性与成本归因 | 谁花了多少钱，能不能按租户/功能拆开 |
第 4 项是 Agent 平台特有的难点 传统平台管代码版本；Agent 平台还要管提示词版本、工具定义版本、Skill 版本、模型版本——而且它们两两之间有兼容关系。Codex 展示了提示词随模型元数据和客户端版本管理；Claude Code 展示了稳定/动态 Section、模型行为补丁和缓存边界。共同结论是：提示词是需要运维和回归的资产，不是代码里的字符串。
最小兼容矩阵应记录：model × system prompt × tool schema × skill/plugin × client/runtime，每次任一项升级都明确要重跑哪些回归集、如何灰度、如何回滚。
如果产品要做扩展生态（Extension / Skill / MCP），要回答四个问题：
| 问题 | 说明 |
|---|---|
| 开发者为什么来 | 用户量？收入分成？解决自己的问题？ |
| 多久能做出第一个能跑的东西 | 超过一天，大部分人会放弃 |
| 怎么调试 | 没有调试手段的扩展生态起不来 |
| 兼容承诺是什么 | 每个扩展点都是一份长期负担（阶段 6） |
| 模型如何发现扩展 | 清单是否增量更新、触发是否强制、是否出现“知道但绕过” |
扩展存在不等于生态有效 Claude Code 的扩展案例说明，生态至少需要三个闭环：当前扩展列表进入上下文、列表变化能增量更新、匹配后有清晰调用语义。应单独评测“模型知道某个 Skill 存在，但选择绕过去自己做”的失败类型。
生态的两个阶段不要搞混 第一阶段是"内部生态"：先让自己团队用扩展机制解决自己的问题。本仓的 35+ 个 Skill 就是这个阶段的产物——它证明了机制可用、沉淀了模式、暴露了缺陷。
第二阶段才是"外部生态"：需要分发、文档、审核、版本管理、收益模型。跳过第一阶段直接做第二阶段，通常做出一个没人用的市场。
2026 年 Agent 产品的定价模式已经比较清晰，主要有六种：
| 模式 | 计费对象 | 适合 | 主要坑 |
|---|---|---|---|
| 按席位（Per-seat） | 用户数 | 传统 SaaS 迁移 | Agent 减少了所需人数 → 自我蚕食 |
| 按 Agent | 部署的 Agent 数 | 明确的"数字员工"叙事 | 客户会问"它顶几个人" |
| 按用量 | token / 调用 / 任务数 | 高频可度量 | 客户预算不可预测，采购难批 |
| 按任务 | 每完成一个动作 | 动作定义清晰 | 定义什么算"完成" |
| 按结果（Outcome-based） | 达成的业务结果 | 结果可客观计量 | "什么算达成"极易起争议 |
| 混合（底价 + 用量） | 承诺额 + 超额 | 大多数 B2B | 复杂度高 |
按席位定价正在被结构性挑战 Agent 的价值主张是"减少所需人力"，而按席位定价的收入随人数增长——这两件事直接冲突。这是 2026 年 SaaS 定价讨论的核心矛盾。
但按结果定价也不是万灵药：它把"什么算达成"的定义权变成了商务谈判的主战场，且要求供需双方对同一套度量口径达成一致——这恰恰要求阶段 10 的评测能力。没有可信的成功率度量，按结果定价谈不下来。
阶段 12 的五项成本（token / 工具 / 基础设施 / 人工审核 / 失败成本）决定了定价的下限。特别是：
| 候选 | 是不是护城河 | 理由 |
|---|---|---|
| 用了什么模型 | 否 | 谁都能用；且每几个月就变 |
| 接了 MCP / 支持 A2A | 否 | 协议是公共品，正在被中立基金会托管 |
| 提示词写得好 | 弱 | 可被复制；有效期短 |
| 独家数据 | 是 | 别人拿不到 |
| 工具闭环 | 是 | 尤其是深入业务系统的写操作能力 |
| 评测集与失败案例库 | 是 | 半年积累，抄不走，且直接决定迭代速度 |
| 工作流嵌入与迁移成本 | 是 | 用户流程改造后的粘性 |
| 信任与合规资质 | 是 | 尤其在金融、支付、出行场景 |
| 分发渠道 | 是 | 谁在用户面前 |
一个自检问题 "如果竞争对手明天拿到我们全部的提示词和架构文档，他们多久能追上？"
答案如果是"几周"，说明护城河在上表的前三行；答案如果是"他们还缺我们的数据、工具权限、评测集和客户关系"，说明护城河在后六行。这个问题应该每个季度问一次。
Agent 进入组织，不是"加一个工具"，是流程再设计。
| 阶段 | 特征 | 典型障碍 |
|---|---|---|
| 个体提效 | 少数人自己用 | 别人不知道有这回事 |
| 流程嵌入 | 某个环节标准化交给 Agent | 责任归属不清：出错算谁的 |
| 流程再设计 | 因为有了 Agent，流程本身变了 | 组织阻力、KPI 冲突 |
卡在第二阶段是常态 大多数组织的 Agent 落地停在"个体提效"，因为第二阶段要回答一个组织问题而不是技术问题：Agent 做错了算谁的？ 没有明确答案，没人敢把 Agent 放进关键流程。
产品经理能做的：把责任边界写进产品——授权矩阵（谁批的）、审计日志（谁做的）、可撤销（怎么补救）。这三样齐了，责任问题才有讨论基础。
| 级别 | 标志 |
|---|---|
| L0 探索 | 个别人在用，无统一入口 |
| L1 试点 | 有明确场景，有人负责，有基础指标 |
| L2 生产 | 有评测集、准入门槛、授权矩阵、可观测性 |
| L3 规模化 | 多场景复用，有模板/Skill 沉淀，有成本归因 |
| L4 再设计 | 流程因 Agent 而改变，组织分工调整 |
这是阶段 13 的 ⭐ 最小产出。
| 通用 Harness | 行业 Agent | |
|---|---|---|
| 卖点 | 能力面、可扩展性、开发者体验 | 把一件具体的事做完做对 |
| 客户 | 开发者 / 平台团队 | 业务部门 |
| 竞争对手 | 大厂的免费产品 | 行业软件 + 人工外包 |
| 护城河 | 生态、分发、开发者心智 | 数据、工具闭环、行业信任 |
| 主要风险 | 被大厂的免费版本吃掉 | 场景太窄，天花板低 |
| 评测难度 | 通用任务集，难以定义"好" | 业务口径清晰，容易度量 |
| 定价 | 席位/用量 | 任务/结果 |
对个人职业发展的含义 这两条路线需要的能力重叠但不相同。通用 Harness 需要的是阶段 6、7、13 的深度；行业 Agent 需要的是阶段 5、10、11、12 加上领域知识。
你手上的素材同时覆盖两条（Pi 桌面端是前者、国际机票 Agent 是后者），这是优势——但作品集要明确以哪条为主线，否则两边都不够深。这个选择在阶段 14 必须做出来。
| 误区 | 纠正 |
|---|---|
| "Demo 跑通了，剩下就是收尾" | 剩下的是 60% 的工作量 |
| "接了 MCP 就有生态了" | 协议是公共品，先做内部生态 |
| "按席位定价最稳" | 与 Agent 的价值主张直接冲突 |
| "按结果定价最先进" | 需要双方认可的度量，前提是阶段 10 的评测能力 |
| "提示词是核心资产" | 有效期短、可复制；评测集和数据才是 |
| "组织落地是 HR 的事" | 责任边界要靠产品设计（授权/审计/撤销）来支撑 |
| "先做平台再找场景" | 没有场景验证的平台，扩展点都是猜的 |
| "同时做通用和垂直" | 资源不够时两边都做不深，作品集尤其忌讳 |
| 资料 | 出处 | 读它拿什么 |
|---|---|---|
| A Practical Guide to Building Agents | OpenAI | 从试点到规模化的组织路径 |
| Building Effective AI Agents（资源库版） | Anthropic | 架构选型与规模化实践 |
| 2026 年 Agent 定价模式对照（多家行业分析） | 行业 | 六种模式与各自的坑；注意分辨营销文与实证 |
| 企业 Agent 生产落地调研（2026） | 行业 | "已在生产"与"持续产生价值"之间的差距 |
本仓已有资料：
商业类资料的可信度分级 定价、市场规模、采纳率这类数字，大量来自内容营销。引用前先看：样本量说了吗？谁做的调研？口径是什么？本讲义对这类数字只描述模式、不引用具体金额与比例，就是这个原因。做方案时同样建议——模式可以借鉴，数字必须自己算。