主题
架构篇整合版
前言 → 2026 Agent 开发者调研报告 → 第 1 章 → 第 2 章 → 认知总图（一页通读）
- 总览
- 前言
- 调研报告
- 第 1 章
- 第 2 章
- 认知总图
一、前言《智以致用：从造出智能，到用好智能》
一句话版（约 20 秒）
智以致用——智能已经造出来了，真正难的是把它"用"好：让 AI 从"会回答问题"，变成"能完成任务、能稳定完成任务"。这是 Agent 架构工作的出发点。
一段话版（约 60–90 秒）
真正难的不是把 AI 造出来，而是把它用起来、用稳。模型仍是智能的源头，却不再单独构成应用架构的中心；瓶颈是怎么把能力组织起来、约束起来，变成能稳定交付的生产力。这里有两道坎必须跨过去：第一，从"会回答问题"到"能完成任务"——Chatbot、Copilot 是人作出判断、模型提供建议；到 Agent 这一层，由智能承担一个环节、一个岗位乃至完整业务流程，人只在关键点做授权、审阅、兜底。第二，从"能演示"到"能稳定"——演示只证明模型有这个能力，生产考验的是系统的确定性：长任务能不能保持状态、工具调用对不对、失败了能不能自己恢复。这两点靠模型本身做不到，所以工程重心放在模型外面的 Harness 上——上下文、状态、工具、权限、观测，这才是 Agent 能不能进生产的关键。最终要做的，是让应用从"被 AI 增强"，变成"由 Agent 围绕目标自己组织"，真正进到核心流程里。
- 立靶：智能商品化，价值在"用"不在"造"
- 两跨：回答问题→完成任务；能演示→能稳定
- 两线：全模态 + 全栈
- 一中心：Harness 工程
- 落点：AI Native → Agent Native
一句话（收尾）
机器可以生成无数种答案，但为什么出发、选择哪一种结果、愿意为哪一种后果负责，仍然属于人。
▍逻辑框架
① 时代背景
思考正在成为「价格快速下降、供给持续扩大」的商品——工业革命解放力，AI 解放认知；人的价值随之转移：提出渴望 · 作出取舍 · 承担责任 · 建立信任。
② 核心命题
智 · 以 · 用：把智能组织起来、约束起来，转化为可规模化交付的生产力。历史类比：蒸汽机先被用来「抽水」，真正重塑社会的是铁路、工厂、城市。
③ 转变一：从「会回答问题」→「能完成任务」：Chatbot/Copilot → Agent / Managed Agent，人在关键处授权·审阅·兜底
④ 转变二：从「能演示」→「能稳定」：Demo 验能力 → 生产验确定性（状态·调工具·失败恢复·可观测·性能成本安全平衡）
⑤ 主线一 · 全模态：理解世界的界面：读·写·看·听·说，应用层变薄，智能下沉为默认能力
⑥ 主线二 · 全栈：规模化供给的经济基础 + 可靠运行的工程前提：模型·芯片·网络·存储·推理·运行时·安全
⑦ 工程中心转移
从「模型」→「Harness 工程」：Agent 运行时与沙箱 ｜ AI Gateway ｜ 工具与协议连接层 ｜ 记忆与技能资产 ｜ 可观测·评估·调试 ｜ 持续学习与自进化闭环
⑧ 工程化挑战
概率智能 → 可靠生产力
⑨ 规模化挑战
单点试验 → 智能基础设施
⑩ 组织化挑战
Agent 孤岛 → 智能组织
⑪ 范式演进（落点）
AI Native → Agent Native：从「被 AI 增强的应用」→「由 Agent 围绕目标动态组织的应用」；从「优化单次调用」→「围绕任务成功交付设计」；从「生产更多 Token」→「更低成本、更高成功率、更确定的结果」。
二、2026 Agent 开发者调研报告（1906 份有效问卷）
一句话版（约 20 秒）
Agent 投入已经成为共识，但生产化仍是少数派：近一半企业已开始开发，真正部署到生产的只有约五分之一，持续迭代的不到一成。卡点不是意愿、也不是模型能力，而是 Harness 层开箱即用的工程配套。
一段话版（约 60–90 秒）
从 2026 年这份开发者调研看，Agent 已经过了"要不要做"的争议期：明确不做的从 22% 降到 15%，已开发或开发中的占到 46%。但真正部署到生产的只有 18%，持续迭代的不到 10%——卡点不在意愿，而在能不能把 Harness 层的工程配套做扎实：状态与上下文在多 Agent 协作里衰减、死锁与成本失控、评估只能靠人工抽查。有三个结论尤其关键。第一，形态不是新旧替代，单 Agent（40%）、多 Agent（42%）、人在回路（15%）长期共存，自主度是可调参数；第二，AI Coding 是唯一规模化的付费场景，但供应商碎片化，可迁移的工程抽象比押注某个厂商更有价值；第三，上下文的问题不在窗口大小，而在写入、淘汰与检索；MCP 缺的不是协议理解，而是注册中心、鉴权、版本、审计这些企业级配套。总的来看，行业正从可行性验证转向可靠性与成本，而评估能力是能不能持续迭代的分水岭——用评估的团队，任务成功率 70% 以上的比例是没有评估体系的约两倍。
- 一个现实：投入共识，生产化少数派（开发46% vs 生产18% vs 持续迭代<10%）
- 一个判断：卡点=Harness 工程配套，非意愿、非模型
- 一个形态观：单/多/人在回路长期共存，自主度可调
- 三类瓶颈：上下文·工具·MCP 的企业级配套
- 一个分水岭：评估能力（人工抽查55% vs 轨迹评估6%）
一句话（收尾）
行业正从"验证可行性"转向"可靠性与成本"——能不能持续迭代，取决于评估能力能不能从人工抽查，变成可规模化的机制。
▍逻辑框架
① 一个现实：投入已成共识，生产化是少数派
明确不做的 22%→15%；已开发或开发中 46%；真正部署生产 18%；持续迭代不到 10%。上线率差距普遍大于开发率差距（上海大型已上线 45% vs 小微 16%）。
② 一个判断：卡点不是意愿、不是模型能力
差异在于是否具备持续演进 Agent 的工程能力——组织与协作、治理、优化与沉淀，即能否把 Harness 层开箱即用的配套补齐。对应成熟度 L1–L4，全书在回答如何从 L2 演进到 L3、L4。
③ 一个形态观：新旧共存，不是替代
单 Agent 40%、多 Agent 42%、人在回路 HITL 15%。选择取决于任务确定性与容错空间，而非技术新旧；混合形态是长期状态，不是过渡阶段；可迁移的工程抽象比押注某个框架更有价值。
④ 三类瓶颈：上下文 · 工具 · MCP
上下文痛点不在窗口大小，而在写入、淘汰与检索（检索不准 54%、记忆更新与遗忘缺失 48%）。工具的组织方式与描述质量比数量更决定成功率（工具过多选择困难 52%、幻觉调用 50%）。MCP 关注/落地 37%，但私有部署仅 9%——差的是注册中心、统一身份鉴权、版本灰度、审计、网关集成这些企业级配套。
⑤ 运行底座：统一入口 + 成本治理
多模型并用已是既定事实，多模型路由与自动降级被 63% 列为最需要的网关能力（全项最高）。可观测里成本归因（50%）先于审计合规——在规模上来之前先建立成本可见性与约束。
⑥ 一个分水岭：评估能力
评估手段仍以人工抽查为主（55%），基于轨迹自动评估仅 6%，公开 Benchmark 不到 5%，28% 没有系统性评估体系。后果体现在成功率：90% 以上仅约一成、70% 以上约 55%、16% 没量化过。用了评估的团队成功率 70% 以上的比例，是没有评估体系的约两倍。
46%：已开发或开发中
18%：部署到生产
63%：最需多模型路由降级
55%：评估仍靠人工抽查
6%：基于轨迹自动评估
三、第 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，但都不是必经的升级阶段，形态演进不等于越高越好。贯穿的原则是：自主性必须与任务风险匹配，为每类任务选择成本与风险可接受的最低充分架构；成熟度 L1–L4 不由产品名称决定。还有一个前瞻：多个 Agent 长期并发运行，调度、隔离、授权、恢复、审计这些操作系统职责会重现，但假设已被运行时生成的执行路径改写——这是 Agentic OS 的伏笔。
- 一个位移：模型从"被调用"→"主动执行"（Coding Agent 验证）
- 一个基石：Agent = Model + Harness
- 一张形态谱：Chat/RAG→Workflow→Copilot→Agentic（非替代链）
- 一条原则：自主性↔风险匹配，最低充分架构
- 一个伏笔：多 Agent 并发→操作系统职责改写→Agentic OS
一句话（收尾）
企业需要设计的不再是一次模型调用，而是一个跨越认知、状态、执行、控制与持续改进的完整系统。
▍逻辑框架
① 架构基石
Agent = Model + Harness —— Model 提供理解·推理·生成·决策；Harness 负责组织·约束并承载执行（Context、State、Memory、Tool、Skill、Runtime、Sandbox、Observability、Evaluation、Governance）。
② 一个位移（拐点）
模型从"被调用的引擎"→"能维持状态、分解目标、调用工具、操作环境、按反馈调整的执行主体"。Coding Agent（Codex、Claude Code、Qoder）最先验证：多步骤、有状态、能操作环境、可接受引导。
③ 形态演进（非替代链）
Chat / RAG→Workflow→Copilot→Agentic Application
区分维度：任务循环由谁掌握 · 执行路径何时确定 · 能否影响外部环境 · 是否跨会话/协作。Workflow 与 Agent 长期共存（确定性流程 + 动态决策的 Hybrid）。
④ 基础形态与两个扩展方向
Single-Agent（基础形态，单个 Agent 在有界任务内闭环）→ 沿时间跨度扩展为 Long-Horizon Agent（跨会话·可暂停恢复·持久状态）｜ 沿协作结构扩展为 Multi-Agent（多角色·编排·移交·评审·权限边界）。可独立采用或组合，均非必经升级阶段。三组概念边界：Agent ≠ Agent 框架；Long-Horizon / Multi ≠ 天然更高智能；应用形态 ≠ 平台形态。
⑤ 决策原则与成熟度
自主性 ↔ 任务风险匹配，为每类任务选成本与风险可接受的最低充分架构。成熟度不由产品名称决定：L1 辅助生成 → L2 受控自动化 → L3 Agentic Execution → L4 规模运营与持续优化。判断是否 Agentic 看六个特征：以任务结果为中心 · 运行时定路径 · 作用外部环境 · 跨步跨请求状态 · 确定性机制约束 · 可观测评估改进。
⑥ 前瞻伏笔 → Agentic OS
多个 Agent 长期并发运行 → 调度·隔离·授权·恢复·审计等操作系统职责重现，但假设被运行时生成的执行路径改写（授权需逐次判定、恢复以任务为单位）→ 呼唤一个承载所有 Agent 的公共治理层，即 Agentic OS（第 30 章展开）。
四、第 2 章《Agentic Application 参考架构》（架构篇收口 · 落位）
一句话版（约 20 秒）
Agentic Application 的核心不是某个框架或模型，而是一组责任清晰、可独立演进、又通过生命周期闭环协作的系统能力。架构用三个视图理解（组件/平台/生命周期）、五个责任域承载、五阶段闭环演进——目的是对每一项被授予的自主性，建立对等的执行、观测、安全和评估能力。
一段话版（约 60–90 秒）
Agentic Application 的架构可以落成一张可执行的蓝图，核心是三条主线。第一，用三个互相正交的视图理解同一套系统：组件视图回答"系统由什么组成"，避免能力遗漏；平台视图回答"在哪里运行、谁负责"，避免责任混乱；生命周期视图回答"如何从决策走向运行并被改进"，避免把一次演示误当成可运营系统——三个视图不能互相推导。第二，五个能力责任域：业务与应用层、Agent 构建与编排层、生产运行层、治理与控制层、调优层，其中 Security 横跨五层。第三，五阶段闭环：架构设计 → 构建 → 运行 → 治理 → 调优，最小可复现单元是 Agent Release（要绑定模型、Harness 编排、Prompt、工具权限、运行环境、评估基线六类要素）；治理既是独立阶段，也是贯穿全生命周期的横切约束；调优产生的变更必须回流到构建、重新过准入门禁，而不是让 Agent 在生产里自由改自己。贯穿的原则是：凡被授予的自主性，都必须有对等的边界、证据和验证；架构的目的不是把系统做大，而是选择与风险匹配的最低充分架构。
- 三个视图：组件（组成）·平台（运行/负责）·生命周期（演进）
- 五个责任域：业务应用·构建编排·生产运行·治理控制·调优
- 五项原则：Model/Harness 解耦·编排/Runtime 解耦·状态外置·自主性↔权限可验证·观测前置
- 三平面：执行面·数据资源面·控制面
- 五阶段闭环：架构设计→构建→运行→治理→调优
一句话（收尾）
架构的目的不是把系统做大，而是对每一项被授予的自主性，建立对等的执行、观测、安全和评估能力。
▍逻辑框架
① 三个视图（理解同一套系统，互不推导）
组件视图=系统由什么组成（避免能力遗漏）｜ 平台视图=在哪里运行、谁负责（避免责任混乱）｜ 生命周期视图=如何从决策到运行并被治理改进（避免把演示误当可运营系统）。讨论任何能力，先确认当前在哪个视图。
② 五个能力责任域
业务与应用层：定义目标·形态·验收，不实现通用能力
构建与编排层：Model+Harness 编排+Context+能力，任务循环
生产运行层：调度·状态·工作区·隔离·恢复·流量·资源管理
治理与控制层：发布·资源·版本·策略·审计
调优层：Trace→评估→候选变更→验证证据
Security 横跨五层，不是单一组件。
③ 五项设计原则
- Model 与 Harness 解耦（模型可替换，不实现强绑定）；2) 编排层与 Runtime 解耦（切换托管不重写任务逻辑）；3) 状态外置、执行实例可替换（长任务恢复前提）；4) 自主性必须与权限和可验证性匹配（最小权限·短期凭证·沙箱·审批）；5) 可观测、安全、评估是运行前提，不是上线补丁。
④ 三个平面（平台责任划分）
执行面（真实跑 Loop·可弹性可失败）｜ 数据与资源面（保存可恢复事实·定义一致性/租户边界）｜ 控制面（版本·身份·策略·配额·审计，集中定义、判定点分布式执行，避免强同步依赖）。
⑤ 关键边界
Context（本次调用看到什么）≠ State（任务已发生什么，需持久）≠ Memory（跨会话经验）≠ Knowledge（组织知识）≠ Skill（怎么做）。Tool/Protocol/Environment 区分；Runtime（管任务生命周期）与 Sandbox（限行动影响范围）边界清晰；AI Gateway 按治理粒度分 LLM/MCP/Agent 三层。
⑥ 五阶段闭环 + Agent Release
架构设计 → 构建 → 运行 → 治理 → 调优，由生产事实驱动新版本。最小可复现单元是 Agent Release（模型·Harness 编排·Prompt/Context Policy·工具权限·运行环境·评估基线六类要素）。调优变更回流构建重过门禁；治理既是阶段也是横切约束。部署形态四选：内嵌 SDK / 托管 Harness 与 Runtime / 托管控制面+私有执行面 / 全自托管。
五、架构篇认知总图（一条递进链）
- ① 前言 · 立意：问题从"造智能"转向"用智能"。两跨（回答问题→完成任务；演示→稳定）· 两线（全模态+全栈）· 一中心（Harness 工程）。
- ② 调研报告 · 印证：46% 开发 · 18% 生产 · 持续迭代 <10%。痛点=Harness 层工程配套：状态衰减、成本失控、评估靠人工。
- ③ 第 1 章 · 定义：Agent = Model + Harness。形态非替代（Single → Long-Horizon / Multi）。成熟度 L1–L4。选最低充分架构。
- ④ 第 2 章 · 落位：三视图（组件/平台/生命周期）· 五责任域 · 三平面 · 五阶段闭环 · Agent Release。给全书建坐标系。
落点：全书坐标系
架构篇为后续四篇建立统一地图：**构建篇（3–6 章）**展开"构建与编排层"、**运行篇（7–12 章）**展开"生产运行层"、**治理篇（13–16 章）**展开"治理与控制层"、**调优篇（17–24 章）**展开"调优层"。
▍架构篇一条线（复述用）
难在"用"（前言）→ 实证在 Harness 配套（调研）→ Agent 是什么（第 1 章：Model+Harness）→ 由什么组成、谁负责、怎么演进（第 2 章：责任域+闭环）→ 全书以此为坐标系展开。
▍概念澄清（两处容易绕的地方）
① 广义 Harness vs Harness 编排层：第 1 章的 Harness 是广义概念——模型之外的全部工程系统（含 Runtime、Sandbox、Observability、Governance）；第 2 章把其中直接组织任务循环的子域拆出来，称为 Harness 编排层。二者是同一概念在不同粒度上的表达，不是两个概念。
② 成熟度 L1–L4 与形态选型：形态选型看任务结构（Single / Long-Horizon / Multi 依任务而定），成熟度看运行与治理能力完备度（能否规模化运营）——两个维度要分开判断，不要用产品名称或"是否多 Agent"来判断成熟度。