主题
第 1 章 · AI 原生应用的新阶段
核心观点 + 逻辑框架（架构篇 · 开篇）
▍速览
一句话版（开场，约 20 秒）
AI 应用进入了一个新阶段：模型从被调用的引擎，变成主动的执行主体。但模型不等于 Agent——真正撑起 Agent 的，是模型外面那层工程系统 Harness。架构基石是 Agent = Model + Harness，企业据此为每类任务选择与风险匹配的最低充分架构。
一段话版（展开，约 60–90 秒）
过去一年，AI 应用的构建起点变了：模型不再只是被应用调用的生成引擎，而是能维持任务状态、分解目标、调用工具、操作环境、并根据执行反馈调整行为的执行主体——Coding Agent 是最早验证这种形态的。但模型获得更大自主权，不等于模型可以独立构成 Agent：任务越长、工具越多、环境影响越大，模型外面的工程系统越关键。所以架构基石是 Agent = Model + Harness，Model 负责理解、推理、生成与决策，Harness 负责组织、约束并承载执行。在应用形态上，Chat/RAG、Workflow、Copilot、Agentic Application 不是一条替代链，Workflow 与 Agent 长期共存；Agentic Application 以 Single-Agent 为基础，可沿时间跨度扩展为 Long-Horizon Agent、沿协作结构扩展为 Multi-Agent，但都不是必经的升级阶段，形态演进不等于越高越好。判断一个应用是否 Agentic，看六个特征：以任务结果为中心、运行时决定部分路径、能作用于外部环境、跨步骤维持状态、自主行为受确定性机制约束、靠可观测与评估持续改进。贯穿的原则是：自主性必须与任务风险匹配，为每类任务选择成本与风险可接受的最低充分架构；成熟度 L1–L4 不由产品名称决定。还有一个前瞻：多个 Agent 长期并发运行，调度、隔离、授权、恢复、审计这些操作系统职责会重现，但假设已被运行时生成的执行路径改写——这是 Agentic OS 的伏笔。
- 一个位移：模型从"被调用"→"主动执行"（Coding Agent 验证）
- 一个基石：Agent = Model + Harness
- 六个特征：任务结果中心·运行时定路径·作用环境·跨步状态·确定性约束·观测改进
- 一条原则：自主性↔风险匹配，最低充分架构（成熟度 L1–L4 不看名称）
- 一个伏笔：多 Agent 并发→操作系统职责改写→Agentic OS
一句话（收尾）
企业需要设计的不再是一次模型调用，而是一个跨越认知、状态、执行、控制与持续改进的完整系统。
▍逻辑框架（记忆卡片）
① 命题：架构基石 Agent = Model + Harness
| Model | Harness |
|---|---|
| 理解 · 推理 · 生成 · 决策，提供认知能力 | 组织 · 约束 · 承载执行，把任务跑起来 |
Harness 承载要素：Context · State · Memory · Tool · Skill · Runtime · Sandbox · Observability · Evaluation · Governance
Agent ≠ Agent 框架：框架只提供 Agent Loop、Tool、Memory 等开发抽象，不会自动形成能围绕目标持续执行、连接业务环境并交付可验证结果的 Agent
Model 与 Harness 边界：Model 是概率性认知核心，不等同于完整 Agent 或完整应用；Harness 不等同于单一 Prompt、简单 Agent Loop 或某个具体框架
Agent ≠ 模型本身：模型提供认知能力，模型外面那层工程系统 Harness 组织上下文、状态、工具与运行约束——真正撑起 Agent 的是 Model + Harness 的组合。
② 机制：一个位移（拐点）
| 过去：被调用的引擎 | 现在：主动执行主体 |
|---|---|
| 应用发起一次调用，模型返回生成结果；无状态、不持有工具、不操作环境 | 维持状态 · 分解目标 · 调用工具 · 操作环境 · 按执行反馈调整行为 |
- Coding Agent 最先验证：Codex · Claude Code · Qoder
- 特征：多步骤 · 有状态 · 能操作环境 · 可接受引导
Coding Agent 是拐点，因为它集中暴露了进入生产要处理的大部分工程问题：上下文超窗、多步状态、工具真实副作用、失败恢复、结果独立验证、人在回路引导。
表 1-1：上一阶段 vs Agentic Application（原书表 1-1）
- 交付物：生成一次回答 → 交付可验证的任务结果
- 会话形态：单轮短会话 → 多步骤、有状态
- 驱动方式：Prompt / RAG 驱动 → Model + Harness 共同驱动
- 环境关系：应用代码调用模型 → 受控边界内用工具操作环境
- 评估对象：输入输出评估 → 同时评估轨迹、环境状态与最终结果
- 演进方式：开发完上线 → 在运行治理评估中持续演进
评估对象从输入输出扩展到轨迹、环境状态与最终结果，是新旧形态在质量口径上的关键差别。
③ 方案：形态演进（非替代链）
Chat / RAG 单轮检索与生成 → Workflow 预定义确定性流程 → Copilot 人在环中辅助决策 → Agentic Application 自主完成任务闭环
区分维度：任务循环由谁掌握 · 执行路径何时确定 · 能否影响外部环境 · 是否跨会话 / 协作
不是一条替代链：Workflow 与 Agent 长期共存——确定性流程 + 动态决策的 Hybrid；资格校验、入账、审批走确定性流程，材料理解、异常调查、方案生成交给 Agent。
④ 基础形态与两个扩展方向
- Single-Agent：基础形态，单个 Agent 在有界任务内闭环
- 沿时间跨度扩展 → Long-Horizon Agent：跨会话 · 可暂停恢复 · 持久状态；核心不是"跑得久"，而是长时间尺度上保持目标、状态、责任与结果一致
- 沿协作结构扩展 → Multi-Agent：多角色 · 编排 · 移交 · 评审 · 权限边界；价值不在增加模型调用，而在让分工、隔离、互校验成为可设计结构
- Long-Horizon / Multi-Agent ≠ 天然更高智能或成熟度：长程增加状态漂移、恢复与成本控制难度；多智能体增加通信开销、共享状态与失败传播——先验证边界明确的 Single-Agent
- 应用形态 ≠ 平台形态：Single / Long-Horizon / Multi 描述任务如何执行；Agent Platform 为多个应用提供共享构建、运行、治理与调优能力
可独立采用或组合，均非必经升级阶段：形态扩展不等于"越高越好"；Long-Horizon 解决"如何跨时间持续"，Multi-Agent 解决"多个执行主体如何协作"，是两个维度。
⑤ 决策原则与成熟度
- 以目标和任务结果为中心：用户给的是任务与可验收结果，不是待回答的问题
- 运行时决定部分执行路径：按中间结果、工具返回与环境状态调整后续行为
- 能够作用于外部环境：调 API · 检索数据 · 改文件 · 跑代码 · 操作浏览器 · 委派 Agent
- 维持跨步骤、跨请求的任务状态：可暂停、恢复、重试或移交执行实例
- 自主行为受确定性机制约束：权限 · 沙箱 · 预算 · 中间件 · 结构化输出 · 人工审批 · 失败处理
- 通过可观测与评估持续改进：记录轨迹与状态，新版本经回归、灰度、审批进入生产
- L1 辅助生成：Chat/RAG/基础 Copilot；任务闭环由人完成 → 门槛：可复用 Prompt · 知识 · 基础评测
- L2 受控自动化：Workflow / 局部用 Agent；预定流程+审批 → 门槛：明确自主边界 · Harness · 工具策略 · 轨迹评估
- L3 Agentic Execution：Agent 持有任务循环；动态规划+持久状态+故障恢复 → 门槛：Runtime · Sandbox · Observability · Security · Evaluation
- L4 规模运营与持续优化：多任务多租户 · 统一治理 · 灰度与持续优化 → 门槛：共享平台 · 组织知识 · 标准 · 自动化
六项特征是判断架构形态的依据，不是必须同时启用的功能清单；成熟度不由产品名称决定：形态取决于任务结构，成熟度取决于运行与治理能力完备度，两者分开判断。决策原则：自主性 ↔ 任务风险匹配，选最低充分架构；只有当前架构无法以可接受风险与成本交付时才有必要升级。
⑥ 前瞻伏笔 → Agentic OS
- 架构决策五问：如何设计架构 → 如何构建 → 如何运行 → 如何治理 → 如何调优；架构设计先于构建，后四者形成持续迭代的工程闭环
- 操作系统职责重现：多个 Agent 长期并发 → 调度 · 隔离 · 资源 · 授权 · 恢复 · 审计
- 但假设被改写：
- 执行单元 = Run（路径运行时决定，可跨进程副本）；状态外置持久；授权每次高影响操作按策略强制判定、可撤销；恢复以任务为单位，重启 ≠ 正确恢复（已发副作用）；审计 = 意图 · 工具调用 · 环境反馈 · 结果关联链路
云与 Kubernetes 是底座不是替代（管 Pod 不管 Run）；需要一个不持有任务语义、为所有 Agent 提供公共运行对象、能力接入、可强制边界与统一证据来源的层次——Agentic OS。收口：能力沿谱系演进、扩展可独立组合；形态与成熟度分开判断；选型只让自主性与任务风险匹配，取最低充分架构。
▍逻辑全景图
逻辑全景图 · 图 1 · 位移与基石：从被调用的引擎到主动执行主体 + Agent = Model + Harness
模型身份位移的两端对照，以及 Model 与 Harness 的工程构成如何合成 Agent。
- 图例：Agent / 执行主体核心 · Model 认知能力 · Harness 工程约束与承载 · 旧形态 / 中性
图 1：位移与基石——模型身份变化 + Agent 工程构成（Mermaid 还原自原精读页图 1）。
读法：① 上半部分是模型身份位移的两端对照——从被动生成引擎到能维持状态、分解目标、调用工具、操作环境并按反馈调整的执行主体，Coding Agent 最先验证；② 下半部分是架构基石：Model 提供理解、推理、生成、决策，Harness 把 Context、State、Tool、Runtime、Sandbox、Observability 等工程能力组织起来并约束执行。面试一句话：Agent = Model + Harness，模型不等于 Agent，自主性越大，模型外面的工程系统越关键。
逻辑全景图 · 图 2 · 形态坐标与成熟度：非替代演进谱系 × Single→Long-Horizon/Multi 扩展 × L1–L4
谱系长期共存，基础形态沿两个方向可独立扩展，成熟度按运行与治理能力分级而非产品名称。
- 图例：Chat/RAG · L1 辅助生成（中性） · Workflow · Copilot · 扩展方向 · L2/L3 · Agentic Application · Single-Agent 基础形态 · L4 规模运营成熟度 · 自主性 ↔ 风险匹配原则
图 2：形态坐标与成熟度——非替代演进谱系 × Single→Long-Horizon/Multi 扩展 × L1–L4（Mermaid 还原自原精读页图 2）。
读法：① 顶部谱系 Chat/RAG→Workflow→Copilot→Agentic Application 是长期共存的形态谱，不是替代链；② 中部 Single-Agent 沿时间跨度扩展 Long-Horizon、沿协作结构扩展 Multi-Agent，可独立采用或组合；③ 下方 L1→L4 是运行与治理能力的成熟度阶梯，与产品名称无关。面试一句话：形态非替代、扩展非必经，选型只让自主性与任务风险匹配，取最低充分架构。
▍书中关键图
① 从 Agent 基础公式到工程架构拆解
原书图 1-1 的拆解关系由本小节下方「六大架构能力模块」三列表格等价承载。
- Model：理解 · 推理 · 生成与决策
- Harness：组织 · 约束并承载执行
Harness 工程落地 → 六大架构能力模块（Agentic Application 的工程拆解）：
| Agent Loop | Context / State / Memory | Tool / Skill / Protocol |
|---|---|---|
| 观察-判断-行动-反思 | 认知输入 · 任务事实 · 跨任务 | 能力封装 · 系统连通 |
| Runtime / Sandbox | Observability / Evaluation | Security / Governance |
| 调度恢复 · 资源管理 · 环境隔离 | 过程观测 · 结果验证 · 持续评估 | 身份权限 · 策略预算 · 审计 |
在应用形态层，Agentic Application = 该执行主体 + 业务逻辑 · 数据 · 工具 · 环境 · 用户交互，交付可验证的业务结果。
示意 · 按正文重绘（原书图 1-1）
② 管理假设的改写：传统软件 vs Agentic Application
原书表 1-5 的逐条对照由本小节下方「管理假设对照表」等价承载。
每项管理假设都被改写：
| 管理假设 | 传统软件（确定性程序） | Agentic Application（运行时决定部分路径） |
|---|---|---|
| 执行单元 | 进程/线程，路径编写时确定 | 任务运行实例 Run，路径运行时决定，可跨进程与副本 |
| 状态 | 随进程内存存活，退出即释放 | 外置 · 持久 · 可恢复，独立于承载实例 |
| 能力接口 | 启动时确定的系统调用与设备 | 运行时动态接入的工具与 MCP 端点 |
| 授权 | 创建时一次授予，越权即拒 | 每次高影响操作按策略强制判定，可撤销 |
| 故障恢复 | 以进程为单位，退出即回收 | 以任务为单位：检查点 · 幂等 · 跨系统补偿 |
| 审计 | 系统调用与文件访问粒度 | 意图 · 工具调用 · 环境反馈 · 结果关联链路 |
示意 · 按正文重绘（原书表 1-5）——两点最要紧：授权不能只在启动时授予，恢复不能只看进程是否存活（重启 ≠ 正确恢复，Run 可能已挂起等待审批并已发出副作用）。
③ 成熟度四档：能力、局限与升级门槛
原书表 1-4 的四档条目由本小节下方「成熟度四档表」等价承载。
| 成熟度 | 能力形态 | 局限 | 升级门槛 |
|---|---|---|---|
| L1 辅助生成 | Chat / RAG / 基础 Copilot（内容生成 · 知识检索） | 任务闭环由人完成 | 可复用 Prompt · 知识 · 基础评测 |
| L2 受控自动化 | Workflow / 局部用 Agent（局部动态决策 · 审批；预定流程 · 结构化输出） | — | 明确自主边界 · Harness · 工具策略 · 轨迹评估 |
| L3 Agentic Execution | Agent 持有任务循环（动态规划 · 工具与环境操作 · 多步骤 · 持久状态 · 故障恢复） | — | Runtime · Sandbox · Observability · Security · Evaluation |
| L4 规模运营与持续优化 | 多任务多租户 · 统一治理（安全 · 评估 · 灰度 · 优化） | — | 共享平台 · 组织知识 · 标准 · 自动化 |
- 判断依据：任务循环 · 执行跨度 · 环境影响 · 生产治理四个维度——不由产品名称或技术标签决定
- 形态与成熟度分开：Single-Agent / Long-Horizon / Multi-Agent 都可以处于 L3 或 L4：形态取决于任务结构，成熟度取决于运行与治理能力完备度
- 升级判断：只有当前架构无法以可接受的风险和成本交付任务，且新增能力有明确价值时才升级
- 分级选型示例：低风险知识助手可长期停在 L1；交易审批系统可选 L2 以确定性 Workflow 保持核心路径；路径难以预知的场景进 L3；规模化多租户高影响操作才需补 L4
- 贯穿决策原则：为每类任务选择成本与风险可接受的最低充分架构
示意 · 按正文重绘（原书表 1-4 成熟度模型）