认知基础与 Agent 认知

一句话：Agent 不是"会调工具的 ChatBot"，而是模型从"被调用引擎"位移为"主动执行主体"后的新形态；Harness 承载执行，形态沿时间跨度与协作结构扩展，成熟度按治理能力分级——三者独立判断，不混为一谈。

适用：2026 年主流大模型 API 与 Agent 框架。概念框架与模型无关，具体产品能力以官方文档为准。

为什么需要

团队在引入 Agent 时最常犯两类错误：一是把 Agent 等同于 Agent 框架，以为用了 LangChain 就有了 Agent；二是在 ChatBot 上叠加工具调用就宣称"已 Agent 化"，上线后却发现任务循环不可控、成本无上限、故障无法归因。根源在于缺少一个统一的认知框架来区分：模型能力与工程系统的边界在哪里、形态演进是共存还是替代、成熟度该用什么尺子衡量。

本文建立三层认知：架构基石（Agent = Model + Harness）、形态谱系（四种形态长期共存）、成熟度阶梯（L1–L4 按治理能力分级）。这不是术语整理，而是选型、故障归因和团队沟通的前提——不知道 Agent 和 Workflow 的区别，就无法判断该用哪种架构；分不清形态与成熟度，就无法向业务方解释"为什么上了 Agent 反而更不稳定"。

核心机制

架构基石：Agent = Model + Harness

Model 承担四项认知能力：理解（解析输入与上下文）、推理（多步逻辑与规划）、生成（产出自然语言或结构化输出）、决策（选择下一步动作）。Harness 承担工程系统的全部剩余责任：

Harness 承载	职责	缺失后果
Context	每轮组装什么信息给模型	模型丢失关键上下文，重复调用
State	任务进度、中间结果外置持久化	进程崩溃即丢失全部进展
Memory	跨会话知识沉淀与检索	每次从零开始，无法积累经验
Tool	工具发现、鉴权、超时、幂等	模型输出调用意图 ≠ 系统允许执行
Skill	可复用任务模板与策略	同类任务反复重写 Prompt
Runtime	调度、并发、恢复、工作区隔离	任务无法跨节点恢复
Sandbox	限定影响范围，隔离执行环境	模型错误直接作用于生产环境
Observability	全链路追踪、Token 计量、延迟分布	故障无法归因，成本无法分摊
Evaluation	离线/在线评测、回归基线	无法量化改进或退化
Governance	权限、预算、审计、合规	自主行为失控，超支无感知

关键区分：Agent 框架（LangChain、LlamaIndex、CrewAI 等）只提供开发抽象（Chain、Agent、Tool 的编程模型），不等于 Agent 本身。框架是 Harness 的一种载体，但 Harness 的完整责任远超框架覆盖范围——托管运行也不等于把责任托管出去。

为什么必须这样切——这条线不是画在"功能"上，而是画在"模型的物理约束"上。模型是一次无状态的概率函数：输入 token 序列，输出下一个 token 的分布，调用结束什么都不保留。由此推出三件事：

1. 状态必须在外面。模型不持有任务进度，所谓"继续上次任务"，是 Harness 每轮把历史、计划、预算重新拼进输入。所以 State/Context/Memory 是循环能转的前提，不是锦上添花。
2. 意图不等于执行。模型输出的工具调用只是一段结构化文本（"我想调 X"），真正发请求、改文件的是执行侧代码。所以鉴权、超时、幂等、审计只能建在 Tool/Runtime/Sandbox 上——建在 Prompt 里等于没建。
3. 正确率不能自己证明自己。模型没有独立的自检通道，它说"已完成"和它编造"已完成"在参数层面是同一个动作。所以 Observability/Evaluation/Governance 必须来自模型之外的证据源。

一句话：表的右列就是"模型做不到的事的清单"。理解了这个，判断一个系统是不是真 Agent 的标准也随之清晰——不是看它会不会调工具，而是看这十项责任有没有被真实承担；缺哪一项，故障就以哪种形式回来。

一个位移：模型从"被调用引擎"到"主动执行主体"

这是理解 Agent 的认知前提。传统应用中，模型是 Pipeline 中的一个节点：接收输入、返回输出、下次调用与上次无关。Agent 中，模型持有任务循环——它决定下一步做什么、何时调工具、何时结束。这不是功能升级，而是角色位移。

Coding Agent 最先验证了这个位移：Codex、Claude Code、Qoder 等产品证明，当模型持有循环并作用于文件系统与终端时，交付物从"一段文本"变为"一次任务的完整结果"。

维度	传统 LLM 应用	Coding Agent
交付物	一段生成文本	任务完整结果（代码变更+测试+PR）
会话形态	单轮或对话	多步任务执行，跨文件跨工具
驱动方式	用户逐步驱动	模型持有循环，自主推进
环境关系	只读或无环境	读写文件系统、执行命令、操作浏览器
评估对象	单轮输出质量	任务完成率、成本、安全性
演进方式	改 Prompt、换模型	改 Harness 策略、加工具、加验证

形态谱系：四种形态长期共存

下图回答“四种形态各自多了什么能力”，并在右侧给出切分它们共用的四个问题：

形态	任务循环	执行路径	外部环境	跨会话	典型场景
Chat/RAG	用户掌握	预设	只读/无	否	客服问答、知识检索
Workflow	框架掌握	预设 DAG	可写	否	审批流、数据管道
Copilot	人机共享	局部动态	有限写	否	IDE 补全、文档辅助
Agentic App	模型掌握	运行时决定	可写	可跨会话	Coding Agent、自动化运维

核心认知：这是谱系，不是替代链。Chat/RAG 不会因 Agent 出现而过时——低风险问答场景用 Chat 就是最低充分架构。四种形态按业务需求独立选择。读图时注意两点：横向箭头只表示后一种形态在前一种之上叠加了什么，不是产品升级路线；四条虚线指向的是同一套判定问题，选型时四条都要过一遍，不能只看其中一条。

基础形态与扩展：沿两个维度独立展开

维度	基础形态	扩展形态	扩展方向
时间跨度	Single-Agent（单会话单任务）	Long-Horizon Agent	跨会话记忆、长任务恢复、持久状态
协作结构	Single-Agent	Multi-Agent	角色分工、并行协作、层级管理

关键认知：Long-Horizon 和 Multi-Agent 是两个独立维度的扩展，可独立采用，不是必经升级阶段。一个 Single-Agent 可以跑小时级长任务（Long-Horizon），也可以多个 Agent 在单次会话内协作（Multi-Agent）。不要陷入"单 Agent 不够就加 Agent"的线性思维。

六项 Agentic 特征：判断是否真正 Agent 化

1. 以任务结果为中心——衡量标准是任务是否完成，不是对话是否流畅
2. 运行时决定部分路径——不是所有步骤预设，至少部分决策在执行中产生
3. 能作用于外部环境——读写文件、调 API、操作数据库，而非仅生成文本
4. 跨步骤维持状态——中间结果、计划、预算跨轮次持久化，不依赖模型记忆
5. 自主行为受确定性机制约束——预算、权限、沙箱、护栏是硬边界，不是 Prompt 建议
6. 通过可观测与评估持续改进——全链路追踪、离线评测、回归基线驱动迭代

六项全满足才是完整 Agentic Application；部分满足可能是 Copilot 或 Workflow，同样合理。

成熟度阶梯：L1–L4 按治理能力分级

成熟度	定义	典型形态	治理要求
L1 辅助生成	模型生成内容，人做最终决策	Chat/RAG/基础 Copilot	基本鉴权、内容安全
L2 受控自动化	流程自动推进，关键节点人工确认	Workflow/局部 Agent	预算限额、步骤审计、异常告警
L3 Agentic Execution	Agent 持有任务循环，自主推进到完成	完整 Agent 应用	五重预算、沙箱隔离、全链路追踪、幂等重试
L4 规模运营	多任务多租户统一治理，平台化运营	Agent 平台	多租户隔离、成本归因、SLA 分级、合规审计

关键认知：形态与成熟度分开判断。一个 Workflow（L2 形态）可以有很高的治理水平（L3 级预算与审计）；一个 Single-Agent 如果缺少预算和沙箱，可能只达到 L2 成熟度。选型原则是自主性与风险匹配，最低充分架构——风险高的场景（写生产库、操作金融系统）即使形态上是 Agent，治理必须达到 L3+。

为什么成熟度用治理能力当尺子，而不是自主能力：自主性是收益轴，治理能力是风险轴；一个只有自主性没有治理的系统，故障模式是"跑飞了没人知道"，它的实际可用等级低于一个更受限但可审计的系统。阶梯每一级新增的不是新能力，而是与之配对的边界：

升级的正确触发条件是"当前级的边界已经被证明可靠"（预算被真实拦截过、恢复被演练过、审计能定位到单次决策），而不是"业务想要更多自动化"。图里每条边标注的是这一级新增的边界和它挡住的失败形态，不是能力清单；缺边界升级等于故障升级。

实战场景

场景：把 Agent 做成多轮提示词——上线后说不清是谁的错

现象：一个电商售后修复助手用框架串了 5 步提示词链就宣称 Agent 化，上线首月任务成功率 61%，每次失败工程师只能写一句“模型答错了”。单条线上故障平均排查耗时 3 人时（经验值，需校准），一周内 4 起同类失败都定位不到根因。

排查过程（按 Harness 十项责任逐格核对，不是先怀疑模型）：拿一条失败 run 回放，问三层问题——那轮模型实际收到的输入能不能还原？Observability 只有 logging、没有 tracing，导不出每轮真实 messages 与工具返回，第一层就卡住。任务进度、预算、已做的中间结果在哪？State 只活在提示词链的变量里，进程重启即归零。模型说“已退款”是执行了还是编的？Tool 侧没有幂等键与审计，区分不了“输出调用意图”和“系统真的执行”。归因清楚：不是模型能力弱，是 Context/State/Observability/Tool 四项责任没被真实承担。

对症做法：先补齐能解释失败的最小 Harness，再谈智能。

harness_gaps:
  observability:
    level: tracing          # 从 logging 升到 tracing：每轮导出完整输入、工具签名、终止原因
    per_step_record: [messages_hash, tool_calls, evidence_refs, cost_tokens]
  state:
    externalize_to: event_log   # 进度/预算/中间结果落外部状态，不放提示词链变量里
  tool:
    idempotency_key: required   # 模型输出调用意图不等于系统允许执行，副作用侧留审计

复盘要点：Agent = Model + Harness，框架只是 Harness 的一种载体；判断是不是真 Agent，不看会不会调工具，看这十项责任有没有被真实承担——缺哪一项，故障就以哪种形式回来。

场景：成熟度跳级——没上评测就放开自主执行

现象：一个自动化运维 Agent 从受控的 L2 直接跳到“模型持有循环、自主推进到完成”的 L3，跳过了评测与预算建设。上线 3 周内出现 6 次跑飞（重复重启服务、误改配置项），单起事故排查 1.5 天（经验值，需校准），月末账单显示单任务成本冲到预算 3.1 倍才被人工掐断。

排查过程（形态与成熟度分开判断）：形态确实是 Agentic App，模型持有循环，没问题；故障要按成熟度尺子对。逐项核对 L1–L4 治理要求：budget_enforcement = none、evaluation = ad_hoc、sandbox = none。自主性已经站在 L3，治理还停在 L1，故障模式正是“跑飞了没人知道”，不是模型不够聪明。触发升级的原因是“业务想要更多自动化”，而不是“当前级边界已被证明可靠”。

对症做法：升级前先给 L3 的四类边界各做一次“被真实拦截过”的验证，再放开自主终止。

L3 前置门槛	验证方式（必须被真实触发过，不是写在文档里）
五重预算	注入一条超长任务，确认 hard_stop 在预算线截断并返回部分结果加终止原因
沙箱隔离	跑一次误删演练，确认写操作被限制在可丢弃的工作区
全链路追踪	任取一次失败 run，能定位到是哪一步、哪个决策出错
幂等重试	同一外部副作用重复提交，确认只生效一次

复盘要点：自主性是收益轴、治理能力是风险轴，两级要同时扩容；缺边界升级等于故障升级。选型原则是自主性与风险匹配、最低充分架构——没跨过 L3 门槛就别让模型持有循环去写生产。

场景：状态存在会话里——跨天任务断链

现象：一个数据迁移 Agent 跑小时级 Long-Horizon 任务，把“做到哪一步”存在进程内存的会话对象里。当天 18:00 节点滚动重启，进行中任务的进度全部丢失；次日从 Checkpoint 恢复时，Agent 以为动作没执行，对同一批表重复写了 3 遍，回滚加补数据花了 2 天。

排查过程（分清是模型、状态还是运行时）：模型是无状态概率函数，本就不持有进度，先排除它。看六项 Agentic 特征第 4 项“跨步骤维持状态、不依赖模型记忆”——没满足。再看 Runtime：会话对象绑死在单实例内存里，换实例不能恢复，正是正文“会话状态第一问：换一个实例还能恢复吗”没过。恢复时又没先清旧 tool_call 中间态，重放把副作用执行了第二遍。根因两层叠加：状态没外置，加上恢复没清中间态。

对症做法：把任务进度从会话里搬出来，落可恢复的外部状态。

long_horizon_state:
  event_log: append_only              # 只追加，记录每步既成事实
  checkpoint_after: [external_call, long_compute, human_confirm]
  session_backend: relational_db      # 从进程内存换成换实例能恢复的后端
  resume_first_step: clear_stale_tool_calls   # 恢复第一件事清中间态，避免副作用重放

复盘要点：State/Context/Memory 是循环能转的前提，不是锦上添花；所谓“继续上次任务”是 Harness 每轮把历史/计划/预算重新拼进输入，进程内会话一崩即全丢。

最小上手

用以下检查表评估一个 Agent 应用的认知定位：

agent_assessment:
  architecture:
    model_responsibility: [理解, 推理, 生成, 决策]
    harness_responsibility: [Context, State, Tool, Runtime, Sandbox, Observability]
    framework_note: "框架是 Harness 的载体，不等于 Harness 全部"

  form_classification:
    current_form: "Chat | Workflow | Copilot | Agentic App"
    task_loop_owner: "用户 | 框架 | 人机共享 | 模型"
    path_determined_at: "设计时 | 运行时"
    affects_external_env: true | false

  maturity_check:
    budget_enforcement: "none | soft_limit | hard_limit | atomic_reservation"
    sandbox_isolation: "none | read_only | write_restricted | full_isolation"
    observability: "none | logging | tracing | full_telemetry"
    evaluation: "none | ad_hoc | regression_suite | continuous"

验收标准：能明确回答"当前形态是什么、成熟度在哪、下一项该补什么"，而不是"我们用了 LangChain 所以是 Agent"。

生产动作

• [ ] 团队统一术语：Agent = Model + Harness，框架 ≠ Agent
• [ ] 按六项 Agentic 特征逐项检查，明确当前应用满足几项
• [ ] 形态与成熟度分开评估，不要混为一谈
• [ ] 选型遵循最低充分架构：低风险场景不上 Agent，高风险场景治理必须到位
• [ ] 建立形态谱系认知：Chat/RAG/Workflow/Copilot/Agent 长期共存，按场景选择
• [ ] 明确模型位移：从"被调用引擎"到"主动执行主体"，错误也会被真实执行
• [ ] 扩展维度独立判断：Long-Horizon 和 Multi-Agent 可独立采用

边界与误区

适用场景	不适用场景
选型阶段判断该用哪种形态	已经确定用 Chat/RAG 后还硬套 Agent
向业务方解释成熟度与治理的关系	向工程师解释具体框架怎么用
故障归因时区分模型/Harness/Runtime/Sandbox	性能调优（这是另一层问题）

常见误区：

1. "用了 Agent 框架就是 Agent" —— 框架只提供开发抽象，Harness 的完整责任远超框架
2. "形态演进是替代链" —— Chat/RAG 不会因 Agent 出现而过时，谱系不是升级路径
3. "单 Agent 不够就加 Agent" —— Long-Horizon 和 Multi-Agent 是独立维度，不是线性升级
4. "形态决定成熟度" —— Workflow 可以达到 L3 治理，Agent 也可能只有 L2 治理

讲清楚

Agent 的本质是模型从"被调用引擎"位移为"主动执行主体"，Harness 承载模型之外的全部工程责任（Context、State、Tool、Runtime、Sandbox、Observability、Evaluation、Governance）。形态沿谱系分布（Chat/RAG → Workflow → Copilot → Agentic App），长期共存而非替代；扩展沿两个独立维度（时间跨度的 Long-Horizon、协作结构的 Multi-Agent），可独立采用而非必经升级。成熟度按治理能力分四级（L1 辅助 → L2 受控 → L3 Agentic → L4 规模运营），与形态分开判断。选型原则是自主性与风险匹配，最低充分架构。

适用：2026 年 Agent 形态与成熟度评估；四级成熟度的判据需按组织治理能力校准 | 初稿 2026-10