阶段 0 讲义 — 从模型到 Agent 产品的四层分工
阶段 0 讲义 — 从模型到 Agent 产品的四层分工
本阶段要回答的三个问题
- "模型"和"Agent"之间到底增加了哪些软件层？
- Harness 与普通 Agent Framework 的本质区别是什么？
- Agent 产品经理与传统 AI 产品经理、平台产品经理的能力差异在哪？
阶段 0 不是"预习"，而是建立坐标系。后面 14 个阶段每一个都会往这张坐标系上挂东西；坐标系歪了，后面学得越多越乱。
一、为什么先讲分层，而不是先讲 LLM
一个反常识的事实：Agent 产品失败的原因，大多数不在模型层。
把一个 Agent 产品出问题的场景摊开，故障归因大致落在这几处：模型没能力、指令写得不对、上下文里没有正确信息、工具契约有歧义、权限设计缺失、会话状态丢了、没有评测所以没人知道它坏了。真正"换个更强的模型就解决"的只有第一类。
这就是分层的意义：它是一套故障归因的语言。当有人说"这个 Agent 不好用"时，能追问到具体是哪一层坏了，是产品经理和研发之间最重要的沟通效率来源。
二、四层分工
分层图（阶段 0 的 ⭐ 最小产出就是把这张图画出来）
Framework 为什么不是独立一层 Framework 是实现手段不是职责边界。LangChain 提供的东西横跨模型调用、工具封装、编排；Claude Agent SDK 直接把整个 loop 打包。所以正确的问法不是"这是第几层"，而是"这个框架替我实现了哪几层的哪些职责"。
每层的产品经理必答题
| 层 | 产品经理必须能回答 | 答不出的后果 |
|---|---|---|
| ① Model | 这个任务需要多强的模型？延迟和成本能否接受？失败时降级到哪个模型？ | 成本失控，或为了省钱选了做不了任务的模型 |
| ② Runtime | 任务跑一半进程挂了会怎样？用户关掉页面任务还在吗？重试会不会重复扣款？ | 长任务永远做不成产品 |
| ③ Harness | Agent 能碰哪些东西？看得到什么上下文？出错时如何被观察到？ | 每次线上问题都要研发捞日志才知道发生了什么 |
| ④ Application | 用户为什么用它而不是自己做？哪些动作必须确认？成功怎么定义？ | Demo 很惊艳，没人日常用 |
三、Harness 与 Framework 的本质区别
这是阶段 0 最关键的一条边界。
Framework 是"你调它"，Harness 是"它调模型"。
更实用的判别方式——列出这九件事，看谁负责：
| 职责 | Framework 通常 | Harness 必须 |
|---|---|---|
| 系统提示词从哪来、怎么拼 | 你自己拼 | 有确定的装配顺序与来源分层 |
| 工具怎么注册、怎么路由、怎么限流 | 提供注册接口 | 有完整管线：校验 → 权限 → 执行 → 呈现 |
| 上下文超了怎么办 | 你自己截断 | 内建压缩/摘要，且可恢复 |
| 会话存在哪、能否恢复分叉 | 通常不管 | 一等公民 |
| 文件系统/命令执行边界 | 不管 | 沙箱是必需品 |
| 危险动作如何确认 | 不管 | 审批策略是必需品 |
| 第三方怎么扩展能力 | 插件接口 | 扩展点是产品面 |
| 一次运行如何被观察 | 回调钩子 | 事件流 + 轨迹 |
| 出错时用户看到什么 | 不管 | 属于产品定义 |
如果一个东西只负责前两行，它是 Framework；如果九行都要答，它是 Harness。
为什么这条边界对求职和方案判断重要 "Agent Harness 产品经理"这个岗位的独特性，正是因为第三层没有现成方法论。传统 AI 产品经理的经验集中在①④，平台产品经理的经验集中在②，而③是这两年才被单独命名出来的一层。本学习路线的重心（阶段 5–11）几乎全部落在③。
参考读物：本仓 Agent Harness 的解剖学 与 Harness Engineering 研究报告，以及 Anthropic 的 Effective harnesses for long-running agents（2025-11-26）——后者给出了一个具体证据：把长任务拆成"初始化 Agent + 每次只推进一点的编码 Agent"，靠留给下一次会话的显式产物跨越多个上下文窗口。这条设计属于③，模型层完全帮不上忙。
四、三种产品经理的能力差异
| 维度 | 传统 AI 产品经理 | 平台产品经理 | Agent Harness 产品经理 |
|---|---|---|---|
| 核心交付物 | 功能定义 + 数据指标 | 能力抽象 + 接入体验 | 能力边界 + 运行时行为 + 治理规则 |
| 需要理解的技术深度 | 模型能力与数据 | API 与集成 | 循环、上下文、工具契约、权限、可观测性 |
| 主要不确定性 | 效果达不达标 | 生态起不起来 | 行为不可预测：同样输入不同路径 |
| 验收方式 | 准确率/转化率 | 接入数/调用量 | 任务成功率 + 轨迹合理性 + 人工接管率 |
| 最容易犯的错 | 把模型当确定系统 | 把协议当价值 | 把 Demo 当产品 |
一句话概括差异 传统 AI 产品经理定义模型做什么，平台产品经理定义别人怎么接，Agent Harness 产品经理定义这个系统被允许怎么行动、行动错了怎么办。
五、常见误区清单
| 误区 | 为什么错 | 正确表述 |
|---|---|---|
| "Agent = 会调工具的模型" | 调工具只是一步；Agent 的定义在于由模型决定循环走向 | Agent = 模型 + 工具 + 状态 + 环境 + 循环 + 停止条件 |
| "上了 MCP 我们就有 Agent 生态了" | MCP 是接线标准，接得上不等于有人用 | 生态的门槛在分发、可靠性和开发者收益，不在协议 |
| "Harness 就是 Prompt 工程做得好" | 提示词只是③里的一个组件 | Harness 还包括工具面、沙箱、会话、权限、可观测性 |
| "模型升级会解决这些问题" | 权限、审计、恢复、成本归因不随模型能力提升而自动出现 | 只有"模型能力不足"这一类故障会被升级解决 |
| "多 Agent 更强" | 编排复杂度换来的是错误放大和不可观测 | 先把单 Agent 的工具面做好，再谈委派 |
| "Agent 产品的核心是对话体验" | 高价值场景常常不在对话框里（后台任务、工作台） | 交互形态是选项，不是前提 |
六、阶段 0 与后续阶段的挂接关系
阶段 0 建立的坐标系，会在这些地方被反复调用：
- ①模型层 → 阶段 1（原理与限制）、阶段 2（API 契约与成本）
- ②运行时 → 阶段 7（生命周期、持久执行、打包分发）
- ③Harness → 阶段 3（上下文供给）、阶段 4（循环）、阶段 5（工具面）、阶段 6（内核架构）、阶段 8（记忆）、阶段 9（编排）、阶段 10（可观测性）、阶段 11（权限与安全）
- ④产品 → 阶段 12（体验与指标）、阶段 13（商业化）、阶段 14（综合项目）
学习路线里两处"分工声明"要一起读 阶段 3 与阶段 8 是同一个问题的两半（单次请求内 vs 跨会话）；阶段 12、13 的产品定义统一收敛到阶段 14 的两个综合项目。这两条在 路线图里已标注，进入相应阶段前回看一次。
七、外部一手资料（阶段 0 精读，约 3 小时）
| 资料 | 出处与时间 | 为什么读它 |
|---|---|---|
| Building Effective AI Agents | Anthropic Engineering，2024-12-19 | Workflow / Agent 边界最被广泛引用的定义，后续所有讨论的公共前提 |
| A Practical Guide to Building Agents | OpenAI，PDF | 从"instructions / guardrails / tools"三件套切入，与上一篇形成对照 |
| Building Effective AI Agents：架构模式与实现框架 | Anthropic 资源库，2026-08 更新 | 单 Agent / 多 Agent / Workflow 的选型讨论，比原文更偏落地 |
| Effective harnesses for long-running agents | Anthropic Engineering，2025-11-26 | Harness 这一层做什么，最具体的一篇 |
本仓已有资料（重读，不是初读）：
- Harness Engineering 研究报告
- Agent Harness 的解剖学
- 工程问题与科学问题的区别
重读方式 这些是此前借助 AI 完成的拆解。重读时先合上文档，凭记忆写出这篇讲的三件事，再打开对照。想不起来的部分才是真正需要读的部分。
Related Documents
- AI 与 Agent 基础知识学习路线
- 术语表
- 阶段 0 实践：能力盘点与分层图
- 阶段 6 讲义：Harness 内核的九个部件