从 AI 原生应用到参考架构

一句话：Agent 不是“模型变强了”，而是模型从被调用的引擎变成了主动执行的主体；真正撑住这个转变的，是模型之外那层组织上下文、约束行动、验证结果、保存状态的工程系统。

对应原书：第 1 章《AI 原生应用的新阶段》、第 2 章《Agentic Application 参考架构》。

为什么需要

只加一个函数调用，不叫 Agent。真正的分水岭是任务闭环由谁完成：

• 过去的应用自己掌握流程，模型只负责生成一段文本；
• Agent 拿到目标后自己决定下一步，会调用工具、读写文件、访问外部系统，失败了还要自己恢复。

一旦走到这一步，六类问题会同时出现：上下文装不下、多步之间状态丢失、工具调用有真实副作用、失败之后不知道怎么续、结果对不对没人验证、高风险动作需要人介入。这些问题都不是“换个更大的模型”能解决的，它们必须由模型之外的一层系统承担。

原书把这一层叫 Harness，并给出最简公式：

Agent = Model + Harness

Model 负责理解、推理、生成、决策，是概率性的认知核心；Harness 负责把离散的判断组织成可执行、可恢复、可验证的过程。任务越长、工具越多、影响面越大，Harness 的权重越高。

核心机制

一、六个特征判断“是否 Agentic”

原书没有用“有没有用框架”来判断，而是给了六个可核对的维度：

1. 以任务结果为中心，而不是以一次回答为中心；
2. 运行时决定部分路径，不是所有步骤都提前写死；
3. 能作用于外部环境：调 API、检索、改文件、跑代码、操作浏览器、委派其他 Agent；
4. 跨步骤、跨请求维持状态；
5. 自主行为受确定性机制约束：权限、沙箱、预算、中间件、结构化输出、人工审批、失败处理；
6. 靠可观测与评估持续改进。

第 5 条最容易被忽略：自主性不是“放开”，而是“用确定性机制围起来”。第 6 条则把 Agent 和一次性脚本区分开——没有轨迹和评估，就无法回答“这次为什么比上次差”。

二、形态与成熟度是两个维度

原书把最容易混淆的两件事拆开了：

维度	看什么	取值
形态	任务结构	Chat/RAG → Workflow → Copilot → Agentic Application
成熟度	运行与治理能力	L1 辅助生成 → L2 受控自动化 → L3 Agentic Execution → L4 规模运营

形态不是成熟度阶梯。一个 Workflow 可以是 L4（流程稳定、治理完备），一个 Agentic Application 也可能停在 L2（能跑，但没有恢复和评估）。同理，Single-Agent、Long-Horizon、Multi-Agent 是三个正交的方向：前者是基础形态，后两者分别沿时间跨度和协作结构扩展，可以单独采用，也可以组合，不存在“必须依次升级”。

这带来一条工程原则：最低充分架构。自主性要和任务风险匹配，只有当现有架构无法以可接受的风险与成本交付时，才升级形态。先上多 Agent 再找问题，通常是在用通信开销换一个本来不需要的复杂度。

三、三个视图与五个责任域

第 2 章给了一套坐标系，回答“这个能力归谁”：

三个视图不能互相推导：组件清单回答不了“谁负责”，平台边界也替代不了生命周期。混用之后的直接后果是故障归属说不清——出了问题，不知道是模型、编排、运行时还是沙箱的责任。Security 不是某一层的一个组件，而是横跨五层的约束。

四、编排层的七项能力

Harness 编排层不是一段长提示词，而是七件必须有人做的事：

能力	覆盖什么	缺失时的表现
Agent Loop 与终止条件	调用、工具、回送、重试、停止、预算	循环停不下来，预算失控
Instruction 与 Context Engineering	指令、历史、工具描述、记忆、检索、环境状态	关键约束被淹没
Planning 与 Delegation	待办、阶段目标、子 Agent、并行、结果聚合	失败后无法定位与续接
Tool 与 Skill 管理	注册、渐进披露、参数校验、结果截断、失败分类	工具错误被当成模型错误
Middleware 与 Policy Hook	调用前后、状态变更前后的权限、审批、审计	策略只靠提示词，可以被绕过
Compaction 与 Continuation	压缩、重置、文件式交接、跨窗口续行	上下文耗尽中断，或压缩改写了事实
Steering / HITL / Verification	运行中修正、关键动作审批、结束前验证	“看起来完成”不可信

这张表的用法不是逐项打勾，而是反查故障：系统出问题时，先判断是七项里的哪一项没做到，再决定改哪里。

五、闭环与发布单元

第 2 章把生命周期收成一个环：架构设计 → 构建 → 运行 → 治理 → 调优 → 回到构建。环上有一个关键约束：调优产生的变更必须重新过发布门禁，Agent 不能在生产里自由改自己。

发布的最小可复现单元叫 Agent Release，绑定六类要素：模型、Harness 编排、Prompt/Context 策略、工具权限、运行环境、评估基线。任何一项单独变化而没有一起记录，都会导致“回滚了但还是不对”或者“同一个版本复现不出同样的失败”。

最小上手

architecture_audit:
  three_views: [component, platform, lifecycle]
  five_domains: [business_app, build_orchestration, production_runtime, governance_control, tuning]
  security: cross_cutting_all_five
agentic_check:
  six_features: [result_oriented, runtime_decides_path, acts_on_environment, cross_step_state, deterministic_constraints, observable_evaluable]
  focus: [runtime_decides_path, acts_on_environment]
orchestration:
  seven_capabilities: [agent_loop_termination, instruction_context, planning_delegation, tool_skill, middleware_policy, compaction_continuation, steering_hitl_verification]
release_unit:
  six_elements: [model, harness, prompt_context, tool_permission, runtime_env, eval_baseline]

给自己现有的系统做一次三视图对账：画出组件图并标出每个组件属于五个责任域中的哪一个；对每个组件写下 owner；用六个特征给当前形态打分；检查编排层七项能力缺哪项就补机制而不是加提示词；列出发布单元六要素缺项补记录；确认 Security 在每一层都有落点。

验收看六件事：每个组件能定位到责任域与人；六个特征中”运行时决定路径”和”外部环境作用”两项真正成立；编排七项能力无遗漏；发布六要素有完整记录；Security 不只停在网关鉴权。

生产动作

• 先定责任边界，再选技术。三视图和五责任域应当在选框架之前完成，否则框架会反向决定架构。
• 把“降级”当成设计对象。模型路由与降级不能只看协议兼容：降级后的模型可能仍能返回合法的工具调用，但多步任务里会丢约束，产出“结构合法、结果错误”的执行。降级必须带着完整 Harness 一起回归。
• 平台做公共对象，不做统一实现。平台统一的是 Agent Definition、Task、Session、Event、Identity、State、Checkpoint、Artifact、Trace、Outcome 这些对象和接入契约；自研、开源、SaaS 的 Harness 各自保留。平台也不替业务定义“什么算正确”，它只汇聚证据。
• 治理前置。审计、策略、评估如果留到上线后补，最后只能落到提示词上，而提示词是可以被绕过的。

边界

• 六特征是判断依据，不是功能清单。六项都“有”但都很弱，仍然是 Workflow 加了一层壳。
• 三视图不能互相替代。只画组件图，回答不了数据在哪里、谁负责；只画生命周期，回答不了边界。
• L1–L4 不是升级路线。很多业务停在 L2 就是最优解，硬推到 L3 会引入恢复、隔离、评估三套成本。
• Agentic OS 不是现在的答案。多 Agent 长期并发确实会让调度、隔离、授权、恢复、审计这些操作系统职责重现，但云和 Kubernetes 管的是 Pod，不管 Run；把“跑在 K8s 上”当成“有了 Agent 运行时”，是当前最常见的概念替换。
• 原书的坐标系偏完整，落地要裁剪。五域三平面是分析工具，不是每个团队都要建五套系统；小团队可以先合并治理与调优，但不能省掉验证。

讲清楚

Agent 的起点是任务闭环的转移：从“应用控制流程、模型生成内容”，变成“模型决定下一步、Harness 负责组织与兜底”。判断一个系统是不是 Agent，看六件事——以结果为中心、运行时决定路径、能作用于外部环境、跨步骤保状态、受确定性机制约束、能被观测和评估；而不是看它用了哪个框架。

架构上先分清三个视图（组件、平台、生命周期）和五个责任域（业务应用、构建编排、生产运行、治理控制、调优），因为故障归属、数据位置和最终责任都靠这套坐标系判断。编排层必须有人负责七件事：循环与终止、上下文、计划与委派、工具与技能、策略钩子、压缩与续行、验证与人机协同。

最后把发布单元固定下来：模型、编排、上下文策略、工具权限、运行环境、评估基线六项一起版本化、一起回滚。做不到这一点，调优就没有可复现的基线。

适用：正在从“模型调用”走向“任务闭环”的团队 | 初稿 2026-10