纯属个人阅读总结，部分描述为个人观点，内容均来自李博杰 - 李老师的开源书本：《深入理解 AI Agent：设计原理与工程实践》，github可下载，在此感谢李老师的无私贡献。本文禁止转载，请自行通过原本总结归纳

1. AI Agent 入门

AI Agent共同点：不再是被动对话，而是能自主规划、调用工具、按结果不断调整策略的智能系统。

本章是全书的概念地图：先给出 Agent 的核心公式，再拆开三大组件，最后落到生产可靠运行的工程框架（Harness）与设计模式。

核心骨架：Agent = LLM（大脑）+ 上下文（眼睛）+ 工具（手脚）

一句话公式：Agent = LLM + [上下文 + 工具 + 约束 + 验证 + 纠正] = Model + Harness。底层模型固定时，提升 Agent 表现最主要的系统工程手段，往往不是换更强的模型，而是重定义或扩展它的"观察空间"与"动作空间"——也就是扩展上下文和工具。

章节1.1.4与1.1.5中存在不同视角的同公式定义：上下文 = 静态前缀 + 轨迹 = 静态前缀 + 动态消息历史 = (系统提示词 + 工具定义) + (用户消息 + 模型回复 + 工具执行结果)，由于书里来回打包的概念产生的新名词，可能会导致阅读理解起来产生疑问，这里先做个等式方便记忆

1.1 现代 Agent = LLM + 上下文 + 工具

• LLM：能力来自两部分：预训练 + 后训练
  • 预训练：积累的世界知识与语言能力
  • 后训练：化的决策策略（监督微调与强化学习）
• 上下文：每个决策点能看到环境信息、用户记忆、领域知识、自身状态与任务进展
• 工具：从预定义的工具调用到按需加载的专业技能（Skills），从动态生成代码创造新能力到委托子 Agent 协作，从主动与用户沟通到响应外部事件。

换个说法：Agent = 大脑 + 眼睛 + 手脚。大脑负责思考决策，眼睛提供思考所需的信息，手脚把决策变成对现实世界的改变。

三个组对应 RL（强化学习）的三个核心概念：

1.1.1 观察空间与动作空间：模型与世界的接口

观察空间与动作空间共同构成 LLM 与外部环境之间的接口——观察空间把环境信息转成模型能处理的上下文，动作空间把模型决策转成对外部世界的操作。没进入观察空间的信息，对模型就像不存在；没进入动作空间的操作，模型即使知道该怎么做，也只能停在文字建议。

在底层模型固定时，提升 Agent 任务表现最主要的系统工程手段，往往就是重新定义或扩展观察空间与动作空间。

重新定义或扩展观察空间与动作空间的成功案例：
Manus：合并原本分离的空间：
率先把三者（Deep Research（深度调研）、Coding（代码生成）和 Computer Use（电脑操控））放进同一个有广泛影响力的生产级 Agent，网络和网页扩大了观察空间，文件系统与代码执行扩大了动作空间，屏幕感知与点击、输入又把图形界面纳入其中。取三类 Agent 观察空间与动作空间的并集，使同一个 Agent 跨越原有产品边界。

OpenClaw：把接口延伸到用户的数字生活：
通过用户已经在使用消息渠道接收任务和返回结果，让 Agent 可以随时随地被触达；同时采用本地优先的 Gateway，通过获得授权的工具、插件和 Skills 连接 Google Drive、Notion 等云应用以及本地文件系统，分散在不同账号与设备中的数字文件都可以在用户明确授权后进入同一个 Agent 的观察空间，并被其工具处理。
（注：Manus 后来也加了 Google Drive 连接器与桌面端本地访问——这再次说明产品能力的演进往往就是观察空间和动作空间的演进。）

扩展空间不等于把所有信息和工具一次性塞给模型：无关上下文制造噪声，过多工具增加选择成本与安全风险。真正有效的扩展应当是按需、相关且可控的——检索把正确信息放进上下文，工具发现只暴露当前需要的动作，并用权限控制和结果验证约束这些动作。

不同类型的 Agent 在感知 / 行动 / 策略三个维度上的展开：

这些Agent系统的共同特征：开放式的动作空间、能内部思考和能持续交互

1.1.2 工具：Agent 的手脚

工具是 Agent 与外部世界交互的桥梁，让 Agent 从被动的观察者变成主动的执行者。

按 Agent 与外界互动的方向，工具分五类：

• 感知工具（信息向内）：→ 让 Agent 访问信息。搜索引擎提供实时网络数据，文件系统读本地文档，API 与数据库对接外部服务和企业核心数据。
• 执行工具（改变向外）：→ 让 Agent 改变世界。代码执行、文件操作、系统命令、外部 API 调用——决策由此变成实际行动。
• 协作工具（横向分权）：↔ 让 Agent 与其他 Agent 分工。委托子 Agent 做专项任务，在关键决策点请求人类确认，或在多 Agent 系统里协调行动。
• 事件触发工具（外部驱动）：← 不是 Agent 主动调用，而是作为外部输入驱动它开始执行——新邮件、定时点、Webhook 回调会激活 Agent 开始后续思考。虽非主动调用，但它是交互通道之一，故归入广义工具体系。
• 用户沟通工具（信息向外）：→ 主动与用户建立连接、传递信息。与执行工具改变外部世界不同，它专注信息传递与交互——文字、语音、邮件把进展或主动关怀传达给用户。

工具设计的质量直接决定 Agent 能走多远：接口不清，模型就乱用；错误处理不到位，工具一失败就成 Agent 的死锁；权限太宽，出错后果难挽回。MCP（模型上下文协议）正让工具接入更像装插件——生态在扩张，但设计原则不过时。

工具调用（Tool Calling / Function Calling）：模型通过结构化的方式调用外部工具

工具调用四步流程：

1. 声明：在上下文里告诉模型有哪些工具可用（名称、用途、参数）。
2. 决策：模型自主判断要不要调、调哪个、传什么参数。
3. 回填：工具执行完，结果追加到上下文。
4. 续推：模型据此决定下一步行动。

这个循环就是后文 ReAct 的基础。设计时先从最窄能力起步。单一日志工具适合记一段过程；受控虚拟工作目录则适合数小时到数天的长程任务，同时保存计划、中间结果、日志与产物，让 Agent 跨多次执行接续工作，目录同样要限定路径、容量、文件类型并防路径越界。

通用工具不总是优于专用工具。支付、删数据、发邮件、生产部署等高风险或强业务约束操作，仍应封装为参数明确、权限受限、全程可审计的专用工具，必要时加预览和人工确认。核心原则：通用基础能力用于组合与探索；专用工具用于约束高风险和强业务规则操作。

1.1.3 LLM：Agent 的大脑

LLM 是决策核心，执行过程：

1. 解析真实意图
2. 模糊复杂任务拆成可执行步骤
3. 执行中持续判断下一步做什么、是否调工具、调哪个、传什么参数

这种"理解—规划—执行"能力来自预训练积累的知识，是工作流与自主 Agent 都依赖的基础。

LLM Agent 的独特能力是内部思考，在行动前先规划推演，不改变外部环境却显著提升后续行动质量。推演不是盲目随机探索，而是在结构化知识（人类知识中沉淀的逻辑规则）上展开。

这带来两个能力的直接体现：

• 零样本泛化（Zero-shot Generalization）：即使面对从未见过的任务，也能通过组合已有知识来处理，无需任何示例
• 少样本适应（Few-shot Adaptation）：提示中给出两三个示范例子，模型就能掌握一种新的任务模式

模型即 Agent（Model as Agent）代表了 AI Agent 发展的最新方向：先进模型经后训练（尤其强化学习）把工具调用内化为原生能力——何时调、调哪个、传什么参都由模型自己定，无需人工编排。但这不意味着框架变不重要，恰恰相反，模型越强，围绕它的 Harness 越关键。

Harness[ˈhɑːnɪs] 原指马具——套在马身上的缰绳挽具，不是限制马的奔跑，而是把力量引向正确方向。在 Agent 中，Harness 包括上下文管理、工具接口、安全约束、验证与纠正等基础设施。

本书立场八个字：方向认同，节奏务实。 方向上不怀疑模型会持续吃掉 Harness（工具调用、长程规划都曾靠外部编排，如今已是原生能力）；但节奏上这个"吃"远比直觉慢——训练以月计，模型也无法一次内化真实业务所有约束与偏好，模型此刻的能力边界，就是 Harness 此刻的价值所在。所以 Harness 工程不是对苦涩教训的抵抗，而是它在工程时间尺度上的实践：模型还做不稳的，Harness 先补上；模型每内化一层，Harness 就卸下一层，转而兜底新的能力前沿。

Agent 的行为改变不只发生在训练阶段。按更新发生的位置和持续时间，有三条互补路径：

• 上下文适应（任务内）：示例、状态、检索结果进上下文，模型立即调整行为，但不改变下次会话的持久状态。快、低成本，受窗口与信息组织约束。
• 外部产物更新（跨任务）：把事实经验整理为知识文档，把可语言化策略写进 Prompt 或 Skill，把确定性流程与约束写成程序与 Harness。可审计、可修订，执行时仍需经上下文或工具接口被使用。
• 参数更新（训练周期）：医疗影像理解、自然语言风格、隐式决策等高维能力，外部规则难完整表达，则需后训练更新参数。部署成本高，却形成自然广泛的泛化。

三条路径不是互斥分类，而是不同时间尺度的协同：上下文负责临场适应，外部产物负责可控积累，参数负责内化难以显式表达的能力。

1.1.4 上下文：Agent 的眼睛

上下文是 Agent 在每个决策点能看到的一切，由五部分构成：

• 系统提示词（System Prompt）：开发者写、全程不变，相当于 Agent 的"岗位说明书"——定义身份、权限、行为准则。还含跨会话保存的用户记忆（偏好、历史、背景）与动态注入的环境状态。
• 工具定义（Tool Definitions）：声明可用工具的名称、功能、参数格式。没有它 Agent 无法识别调用任何工具——消融实验（实验 1-1）会验证。它与系统提示词构成全程不变的静态前缀（2026 年起生产框架也可按需把完整 schema 动态加载到上下文末尾而不破前缀）。
• 用户消息（User Messages）：用户输入，可能含经 RAG 动态检索引入的外部知识（覆盖训练数据截止后的信息或私有领域知识）。
• 模型回复（Assistant Messages）：模型之前生成的回复，最多含三部分——思考过程（reasoning，保连贯与可解释）、文本内容（content，对用户的回复）、工具调用请求（tool_calls，采取行动的方式）。三者不一定同现：调工具时通常只有 reasoning + tool_calls，给最终答案时通常只有 reasoning + content。
• 工具执行结果（Tool Results）：Agent 框架执行工具后返回，是下一步思考的直接依据，也让它从结果中学习、避免重复犯错。

前两项（系统提示词 + 工具定义）是静态前缀；后三项（用户消息 + 模型回复 + 工具执行结果）是随交互增长的动态消息历史。五部分共同构成每次推理的上下文。

实验 1-1 消融实验（Ablation Study）：探索了不同上下文组件对 Agent 行为的影响。五组对照实验包括：一组保留全部组件的完整基线，再加上四组各缺失一个组件的对照，以此观察每个组件对 Agent 性能的影响。

上下文消融试验设计

逐一去掉组件的结果：

• 去掉工具定义 → Agent 完全丧失行动能力（不识别任何工具）。
• 缺工具执行结果 → 看不到上一步反馈，反复调同一工具，陷入无限循环。
• 剥离思考过程 → 前后决策互相矛盾。
• 缺历史消息 → 等于失忆，从头重跑整个任务，重复已完成步骤。

个人总结：静态前缀（提示词与工具定义）是Agent 行动能力的基础。工具执行结果是闭环控制的关键。思考过程保留之前的决策原因，使思维更加连贯，避免做出前后矛盾的决策。历史消息防止冗余操作，保持任务执行连贯性，避免重复犯同样的错误。

（系统提示词作为基本身份定义不参与消融——没有它 Agent 连角色认知都没有。）每个组件的作用都有实验证据支撑，不只是理论推断。

1.1.5 ReAct 循环

Agent 的三大组件协同的核心机制是 ReAct（Reasoning + Acting）。循环含三个环节：模型先思考当前该做什么，再调工具行动，然后观察工具返回结果并继续想下一步。这个"想→做→看→想→做→看"的循环不断重复，直到任务完成。

轨迹（trajectory）轨迹是 Agent 在执行任务过程中不断积累的消息历史——用户消息、模型回复（包括思考过程和工具调用）、工具执行结果。

站在ReArc视角，Agent 的上下文 = 静态前缀 + 轨迹（1.1.4里api视角中的动态消息历史，同个东西）。轨迹随交互增长，基于完整上下文，LLM 生成下一步响应，响应再追加进轨迹，供下次调用使用。

ReAct设计的精妙处：
上下文的累积性：每次调用都能看到完整轨迹，于是理解自己处于任务哪阶段、尝试过什么、得什么结果，Agent 通过轨迹保持着对整个任务的全局认知。
轨迹的结构化：用户消息、模型回复（思考过程 + 工具调用）和工具执行结果被清晰地区分开来，也带来高度可解释性与可调试性。
轨迹不仅是执行记录，更是能力的体现：分析大量轨迹可发现行为模式、优化决策、改进工具，甚至总结进知识库或通过强化学习训练更好的模型，形成从经验学习的闭环。

"模型即 Agent"实例（验证编排循环从客户端移到服务端，决策权交给模型）：

• 实验 1-2 · Kimi K3：约 2.8 万亿参数 MoE （主流神经网络架构）模型，100 万 token 上下文、原生视觉、常开思考模式；经 RL 把"何时调、调哪个、传什么参"内化为原生能力，客户端无需写编排逻辑。它自主决定何时搜、搜什么，据结果动态调策略。突出优势是长链工具调用稳定——能连续 200～300 次调用而保持思考一致，远超多数模型数十次后退化。被内化的是"用不用、怎么用"的决策，工具本身（web_search、code_runner）仍由服务端 Formula 脚本引擎执行。
• 实验 1-3 · GPT-5.6：用 Responses API 把"搜索—阅读—分析"在服务端闭环。便利特性是自由格式工具调用（type: "custom"，允许直接发原始文本如一段 Python、一条 SQL，免 JSON 转义——是 API 参数格式演进，非架构革新）。还有 Verbosity（详略）与 Reasoning Effort（思考深度）参数。最值得关注的是意图澄清：收到任务不立即执行，先提问确认真实需求（如"偏好哪个数据源？分析哪些指标？"），弥合"说了什么"和"真正想要什么"之间的差距。

澄清一个误解：RL 赋予模型的是决策能力（何时调、调哪个、传什么参、如何串联成连贯推理），而工具本身及其执行由框架/API 内置工具提供（真实实现、沙盒、发起与回传都在模型之外）。RL 优化决策策略，不是把搜索引擎或代码沙盒装进权重。 编排循环没消失，只是从客户端移到服务端，决策权交给模型。

1.2 Harness 工程：模型之外的竞争力

前半章回答了 Agent 是什么，下半章回答它如何在生产环境可靠运行。前面实验证明基本机制有效，也暴露脆弱点：模型可能幻觉（编造不存在的工具或参数）、选错工具、遇错无法自愈。能跑的 Demo 与可靠产品间有巨大鸿沟，这些脆弱点正是 Harness 工程要解决的。

Agent = LLM + 上下文 + 工具 描述内部组成（大脑/眼睛/手脚由谁承担）。从工程视角，把 LLM 当作核心组件（Model），围绕它构建的支撑代码统称 Harness。两者不是替代，是同一系统的不同抽象层。之所以换用更通用的 "Model"，因为 Harness 原则适用于任何具备推理与工具调用能力的模型。Harness 核心即原公式的"上下文 + 工具"，再加三层保障：约束（限定能做什么/不能做什么）、验证（检查做得对不对）、纠正（做错怎么补救）。

展开生产形态：

最小公式（Demo 视角）：Agent = LLM + 上下文 + 工具
生产公式（生产视角）：Agent = LLM + [上下文 + 工具 + 约束 + 验证 + 纠正] = Model + Harness

最小公式能跑起来；生产环境长期可靠还需补全约束、验证、纠正三层外壳——约束防越界、验证发现错误、纠正恢复异常。这三层不是独立模块，而是围绕"上下文 + 工具"构建的保障层；生产公式完全包含最小公式，并在外围加了一圈安全网。

退款例子：上下文中嵌入退款政策是"上下文"，校验退款金额不超订单金额属"约束"；工具执行 API 调用是"工具"，API 超时自动重试属"纠正"。没有 Harness 时：模型看不到退款政策（缺上下文）、不知调哪个 API（缺工具）、编造退款结果（缺验证）、用户发现根本没退（缺纠正）。有了 Harness：系统提示词写明 7 天政策（上下文），调 query_order / process_refund（工具），框架校验金额不超订单（约束），校验数据库确认成功（验证），超时自动重试（纠正）。同一个模型，有无 Harness，结果天壤之别。 回到马具隐喻：没有 Harness 的模型像脱缰野马——能力惊人，却无法可靠完成任务。

更精确地说，模型之外的全部基础设施都属 Harness。Harness 五功能：

上下文与工具让 Agent "能做事"，约束/验证/纠正让 Agent "不做错事"——它们不是独立于上下文工具的额外物，而是确保其在生产中可靠运转的实践。成熟度曲线上，两者重要性不对称：早期框架重心在上下文与工具（让它能做事），生产级系统重心已转向约束、验证、纠正：确保工具调用是安全的、上下文是经过管理的、错误是可恢复的

以 Claude Code 为例，它的 Harness 中绝大部分代码是约束、验证、纠正，而非上下文与工具——工具（文件读写、命令、搜索）只是一小部分，真正核心的是围绕这些工具构建的保障机制：

• 流程状态管理：追踪 Agent 当前执行到哪一步
• 多层上下文压缩：当信息太多时自动精简
• 权限分类：控制哪些操作需要用户确认
• 熔断器（Circuit Breaker）：当错误连续发生时自动“断电”停止重试，防止整个系统崩溃
• 错误恢复机制：捕获异常、回滚到上一稳定状态、重试或交还给人类”

1.2.1 从提示工程到 Loop 工程：工程范式的演进

回顾 AI 应用工程的演进弧线：

1. 软件工程：基础——传统系统设计、架构、测试、部署。
2. 提示工程：优化输入给模型的自然语言指令来提升输出质量。
3. 上下文工程：系统性管理模型能看到的所有信息（系统指令、工具定义、对话历史、外部知识）。
4. Harness 工程：涵盖了约束机制、验证手段、反馈循环和错误恢复等模型之外的全部基础设施。
5. Loop 工程：把视野从单次运行扩展到跨轮次的持续自主运转：谁来发现下一件该做的事、何时验证、何时才算真正完成。
6. Graph 工程：把 Agent 循环、确定性程序、人工审批组织成显式执行图，节点承担具体能力、边规定路由与依赖。它不是 Loop 工程的替代品，也不宜视为演进链的"第六层"——循环本身就是带回边的图，单个节点仍可跑 ReAct。此名称未稳，本书视为对既有编排与 Harness 实践的新称呼（"图"指控制流或执行图，非 GraphRAG 知识图谱）。

核心判断：这五个阶段不是替代关系，而是层层包含——每一层都在前一层的基础上扩展了工程师的关注范围和影响力。当各家模型的能力越来越接近、不再是决定性的差异因素时，竞争优势就转移到了模型之外的工程实践。

这一判断有实证：LangChain 在 Terminal Bench 2.0（评估 Agent 在终端完成复杂任务的基准）上，Coding Agent 从 52.8% 提升到 66.5%（排行榜从 30 名外跃升前 5）——改变的不是模型，而是 Harness：让 Agent 自动检查执行结果、检测是否陷入重复循环、优化思考策略。OpenAI 工程团队也分享类似经验：3 名工程师 5 个月完成约百万行代码、近 1500 个 PR，达传统速度约 10 倍——背后不是模型多强，而是 Harness 做对了。

1.2.2 Harness 五功能的核心原则

五功能构成闭环：上下文与工具支撑决策，约束预防错误，验证发现偏差，纠正闭合循环。缺任一环节都有可靠性缺口。

1.2.3 构建有效 Agent 的核心原则

据 Anthropic 经验，成功的 Agent 系统遵循三原则：

1. 保持简单：从最简单方案开始，只在必要时加复杂度。直接 API 调用优于复杂框架，清晰代码优于聪明抽象——每多一层抽象都是调试时的新盲区。
2. 保持透明：明确显示规划步骤、执行日志、决策轨迹——不只为调试，也是让用户建立信任的前提。黑箱里的错误一旦发生，外部既无法定位也无法纠正。
3. 设计好工具接口（ACI，Agent-Computer Interface）：从 Agent 视角而非程序员视角设计接口。命名参数要直观，易误用的地方从设计上让错误无法发生——如 SIM 卡缺角只能单向插入、微波炉门没关绝不加热。这种"用设计消除错误"在制造业叫防呆（Poka-yoke，源自丰田）。设计不好的工具会让再强的模型也频繁出错——模型与工具唯一沟通通道就是接口本身，模糊接口会被模型放大成系统性错误。

1.2.4 如何选择模型

模型是智能基座，选对往往比优化提示更有效，别只看排行榜，要在自己任务上评估（第六章）。

• "御三家"：

  • OpenAI（GPT/o）：均衡、用户最多
  • Anthropic（Claude）：复杂推理、编程、工具调用突出
  • Google（Gemini）：超长上下文与多模态强，适合长文本与多媒体

• 国内模型：部署在国内或有较严格的成本预算，国内模型是务实的选择。但工具调用能力差异大，选型前务必实测。

  • 豆包：国内延迟极低、适合实时
  • Kimi ：国内 Agent 能力较强的
  • Qwen、DeepSeek 等开源Agent：在成本与可定制性有优势。

• 开源 vs 闭源：

  • 闭源：通常领先但成本高、受 API 策略限
  • 开源：成本低、可私有化、支持微调，适合成本敏感或数据合规。

• 能力之外看策略边界：模型在基准具备某能力，不意味着承载它的产品允许用户调用。厂商对网络、蒸馏、隐私、高风险操作设不同边界；同一任务在聊天产品、Coding Agent、API 中可能结果不同。选型不能只比准确率/价格/速度，还要测：模型是否愿意执行、接口是否暴露所需能力、服务条款是否允许。业务关键任务提前准备人工接管或合规模型作替代。

• 绝大多数 Agent 需支持思考（Reasoning）的模型：多步思考、工具选择等复杂决策，无思考模型表现往往很差。仅极少数例外（单步简单任务、Computer Use 点固定位置）。

• 关注输出速度与多模态：输出 token 速度直接决定端到端延迟（20 轮推理每轮慢 2 秒就多等 40 秒）；需理解图/音/视频时多模态是硬性要求。

1.2.5 编排模式：工作流与自主

编排模式是 Harness 中"上下文与工具"的组织方式——决定上下文如何在调用间流动、工具如何调度、执行路径是预设还是动态生成。原则：从简单到复杂——先考虑单个 LLM 调用（优化提示和示例能解决就不引 Agent）；需多步且能清晰分解为固定子任务时用工作流；需动态决策和灵活路径时才用自主 Agent。Agent 通常用延迟和成本换性能，要谨慎权衡。

工作流（Workflow）：预定义代码路径编排 LLM 与工具，执行路径确定、由开发者写死，LLM 只在节点内部理解生成。以订机票为例：核实身份→搜索航班→完成付款→确认预订，四节点固定流转（不会付款前预订、身份核实前搜索）。两核心优势：①严格流程控制（"付款前不能预订"等业务规则代码强制，不靠 LLM 判断）；②安全（路径确定，提示注入或犯错最多影响当前节点，攻击面受限）。局限是缺乏变通——预设未覆盖的情况（临时改签、航班取消）只能走异常分支或交还人类。

自主 Agent（Autonomous Agent）：执行路径非预设，由 Agent 据环境反馈实时决定。仍以订机票：用户说"订下周三去上海的机票"，Agent 自行决定先搜航班、发现需登录于是先核实身份、再回来搜、发现最便宜需转机主动问用户、用户说不要转机再调条件……它需要自主规划、识别失败调策略，而非出错就停。但自主性≠无限制——必须设明确停止条件（任务完成、达最大迭代、遇不可恢复错误），否则易死循环或过度执行。实现上本质就是循环里用工具的 LLM（ReAct 循环），退出条件常为：调用最终输出工具、模型返回无工具调用的响应、遇错或达最大轮次。适用于开放式问题（SWE-bench 修 Issue、Computer Use 操作界面、迭代研究）。部署须沙盒充分测试、设护栏监控、关键决策点加人机检查点。

混合使用：工作流与自主非此即彼。关键、强合规流程用工作流保可靠，需灵活决策处切自主。如 n8n 用可视化拖拽在同一系统里同时放工作流节点和自主 Agent 节点。

主流框架简要对比：

随"模型即 Agent"深化，框架核心价值不再只是编排 LLM 调用——模型越来越能自主决策，但围绕它的上下文管理、工具生态、安全约束、错误恢复等 Harness 反而更重要。选框架关键不在自身复杂度，而在能否以最小抽象层让你专注业务逻辑。

1.2.6 护栏与安全性

本节仅高层概览，细节见第二章（提示注入防护）、第四章（工具权限）、第五章（代码执行安全）。

护栏是 Harness 中"约束、验证、纠正"的核心落地手段——分层防御的韧性防线，管理数据隐私（防系统提示泄露）或声誉风险（保行为与品牌一致）。先针对已识别风险设护栏，发现新漏洞再逐步加。单个护栏不够，多个专门护栏组合才有韧性。

护栏也有另一类失败——误拒绝：为降危险请求放行率，可能同时拒掉一部分合法但形式敏感的任务（如授权的安全测试、评估、蒸馏研究）。所以护栏评估不能只测"应拒的是否拦住"，还要测"明确允许的能否正常完成"；理想系统对合法敏感任务应提供解释、人工升级或授权执行路径，而非笼统拒绝。

护栏类型（按防护位置）：

• 输入侧（请求到达前拦截）：相关性分类器（标记偏题，如编程助手收到"帝国大厦多高"）、安全分类器（检越狱与提示注入——越狱是用户自己绕过安全限制，提示注入是攻击者经外部数据间接操纵模型）、内容审核（暴力和歧视等）、基于规则的保护（黑名单、长度限制、正则过滤，防 SQL 注入）。
• 执行侧（工具调用时验证）：核心是工具风险评级——按操作是否可逆、权限等级、财务影响标注风险（低/中/高），高风险需额外审查或人工确认。
• 输出侧（返回用户前检查）：PII 过滤器（防不必要暴露身份证号、手机号）、输出验证（保回复与品牌一致）。

代表性工业实践——Anthropic Constitutional Classifiers：①规则驱动——用自然语言"宪法"（允许/禁止）生成合成训练数据训分类器；②上下文联合判断——把用户提问和模型回答放一起查（单独看"如何用食品调味料"无害，对照提问才知是化学试剂暗语）；③两级筛查——先用极轻量探针（读模型内部激活，近零成本）查所有对话，可疑再交更强分类器复审，第一级误报多也不影响体验、成本大降。

人工干预（Human in the loop）：关键保护措施，让 Agent 不损体验地提升实际性能，部署早期尤为重要（识别失败模式、发现边缘情况、建评估周期）。两种触发：①超过失败阈值——设重试/操作次数上限，超限（如多次仍不理解客户意图）升级人工；②高风险操作——敏感、不可逆、高风险（取消订单、大额退款、付款）触发人工监督，至少团队建立信心前如此。

一句话带走 + 跨章钩子

一句话带走：现代 Agent 的本质是 大脑（LLM）+ 眼睛（上下文）+ 手脚（工具）；当模型固定，扩展观察空间与动作空间（上下文与工具）往往是比换更强模型更直接的杠杆。而把 Demo 变成可靠产品的，是模型之外那一圈 Harness——上下文与工具让 Agent "能做事"，约束、验证、纠正让它"不做错事"。

跨章钩子：第 2 章上下文工程 = 把"眼睛"落成工程（静态前缀 + 动态轨迹、KV Cache、提示工程、Agent 状态栏、上下文压缩）；第 4 章工具 = 五类工具的分工与权限、MCP、异步架构怎么把"手脚"做稳；第 7 章后训练 = RL 如何把工具调用与决策策略内化为模型原生能力，以及 Harness 反馈信号如何写回参数；第 10 章多 Agent / Loop 工程 = 自主循环与 Graph 编排、多 Agent 间的约束与纠正如何落地。关于 Agent 在 RL 中的学术渊源与传统 RL 对比，也在第七章系统展开。