AI Agent 入门笔记：从会聊天，到真正把事情办完

本文是对第一章《AI Agent 入门》的学习整理。重点不是记住所有框架，而是建立一套分析 Agent 的坐标系。

上一篇：读《引言》：真正耐用的 Agent 知识，来自实践而不是热词。

写在前面：Agent 和聊天机器人差在哪里？

聊天机器人最擅长的是“回答”；Agent 真正要解决的是“完成”。

Cursor 会搜索代码、修改文件、运行测试；Deep Research 会搜索、阅读、比较并整理报告；电脑操控 Agent 会观察界面、点击按钮，再检查操作是否生效。这些产品形态不同，却都跨过了一条边界：模型不再只生成文本，而是进入一个持续的“观察—行动—反馈”闭环。

所以，判断一个系统是不是 Agent，我不会只看它是否用了 LLM，而会看三个问题：

  1. 它能看到哪些真实环境信息？
  2. 它能对环境执行哪些动作？
  3. 它能否根据动作结果继续调整策略？

第一张认知卡片：Agent 的核心公式

第一章最重要的公式仍然是：

Agent = LLM + 上下文 + 工具

组件 直觉 负责什么 常见失败
LLM 大脑 理解意图、规划、决策 推理错误、幻觉、策略不稳
上下文 眼睛 提供任务、历史、状态与观察 信息缺失、污染、窗口溢出
工具 手脚 读取或改变外部世界 接口误用、权限过大、执行失败

这里还有一条必须守住的边界：Environment 不是 Agent 的组成部分。 文件、数据库、网页、用户和物理世界属于环境；Agent 通过观察与行动接口和它们交互。

从生产架构看，Agent 内部还可以再拆成：

Agent = Model + Harness

Model 负责做决策；Harness 则是包围模型的运行与治理层，负责组织上下文、暴露工具、维护循环、控制权限、验证结果并处理错误。

这两个公式并不冲突。前者是全书的概念骨架，后者是把“上下文 + 工具”展开为生产工程职责。

能力提升的杠杆：扩展观察与动作空间

一个很容易忽视的结论是：模型固定时，最有效的改进往往不是继续优化 Prompt，而是让 Agent 看见更多必要信息，或获得更合适的行动接口。

例如：

  • 看不到仓库文件，Coding Agent 就无法理解项目；
  • 没有终端工具，它只能建议你运行测试；
  • 没有浏览器观察，它无法知道按钮是否真的被点击；
  • 没有支付权限，它最多生成一份付款说明。

但空间并非越大越好。开放文件系统、命令执行和网络访问会同步扩大攻击面。因此更准确的原则是：按任务需要扩展能力，用最小权限、沙盒和验证约束风险。

工具不是 API 清单，而是 Agent 的“动作语言”

第一章把工具分为五类：

工具类型 信息/动作方向 例子
感知工具 环境 → Agent 搜索、读取文件、查询数据库
执行工具 Agent → 环境 写文件、运行代码、调用业务 API
协作工具 Agent ↔ 其他角色 委托子 Agent、请求人工确认
事件触发工具 环境主动唤醒 Agent 新邮件、定时器、Webhook
用户沟通工具 Agent → 用户 消息、邮件、语音通话

工具设计有一个很实用的取舍：

  • 通用工具适合探索与组合，例如受限的代码解释器；
  • 专用工具适合高风险操作，例如付款、删除数据和生产部署。

我把它概括成一句话：低风险任务给自由度，高风险任务给窄接口。

ReAct：Agent 是怎样一步步工作的

ReAct 是 Reasoning + Acting 的缩写，但实际包含三个动作：

思考 → 行动 → 观察 → 思考 → 行动 → 观察 → …… → 完成

每一轮都会把新信息追加进轨迹（trajectory）。模型下一次决策时，看到的是：

上下文 = 静态前缀 + 动态轨迹

  • 静态前缀：系统提示词 + 工具定义；
  • 动态轨迹：用户消息 + 模型回复 + 工具执行结果。

一个最小循环可以写成：

trajectory = [user_request]

while not done:
    context = stable_prefix + trajectory
    decision = Model(context)
    trajectory.append(decision)

    if decision.has_no_tool_call():
        return decision.answer

    observation = Environment.execute(
        Harness.validate(decision.tool_call)
    )
    trajectory.append(observation)

这段伪代码里最关键的不是 while，而是 observation。没有真实结果回流，循环就不是闭环，模型只能假设动作已经成功。

上下文消融实验给我的警告

实验 1-1 逐一移除上下文组件，最值得记住的不是“所有内容都同样重要”，而是它们的作用并不等价：

  • 缺少工具定义：Agent 无法行动，却仍可能生成一份看似可信的答案；
  • 缺少工具执行结果：Agent 不知道动作是否成功，容易盲目重试；
  • 缺少历史消息：Agent 更可能重复操作和再次犯错；
  • 缺少 reasoning：如果理由能从结果重建，影响可能并不明显。

这带来两个工程结论。

第一，“有答案”不是成功条件。最危险的失败往往不是报错，而是输出一份格式漂亮、事实却未经观察验证的结果。

第二，不能凭直觉宣称某个上下文组件“不可或缺”。模型会变化，信息也可能从别处重建，正确方法是做消融评估。

实验代码与当前验收状态可从第一章实验导航和实验验收台账进入。

从 Demo 到产品：Harness 五要素

一个 Demo 只要能跑起来；生产系统还要能约束、验证和恢复。第一章把 Harness 拆成五项职责：

要素 关键问题
Context 模型是否看到了做决策所需的信息？
Tools 接口是否清晰、可组合、难以误用？
Constrain 哪些动作允许执行，哪些必须拒绝或确认？
Verify 如何通过外部证据判断结果正确？
Correct 失败后如何重试、回退、熔断或转交人工？

它们组成两个层次：上下文和工具让 Agent 能做事；约束、验证与纠正让它 可靠地做事。

我认为这也是第一章最现实的判断：当模型能力逐渐商品化，产品差异越来越多地来自模型之外的工程。用户最终感知的不是基准测试分数，而是任务能否完成、错误能否恢复、风险是否可控。

工程范式为何越来越“向外扩”

第一章梳理了一条很有启发性的演进路径：

Prompt Engineering
    ↓ 管理全部输入信息
Context Engineering
    ↓ 管理模型运行与环境交互
Harness Engineering
    ↓ 管理跨轮次持续运行
Loop Engineering
    ↓ 组织循环、程序与人工审批
Graph Engineering

它们不是互相替代，而是关注范围逐层扩大。Prompt 仍然重要，只是它现在被放进了更完整的系统问题中。

这也提醒我：如果任务失败，不要习惯性地只改提示词。问题可能出在上下文选择、工具接口、状态流转、停止条件、权限或验证机制上。

工作流还是自主 Agent？

两者的根本区别不是“有没有 LLM”，而是执行路径由谁决定。

对比项 工作流 自主 Agent
路径 开发者预先定义 模型根据反馈动态决定
优势 可预测、易审计、流程约束强 灵活，能处理未知步骤和例外
代价 难以覆盖预料外情况 成本更高，错误可能复合传播
适合 支付、审批、固定业务流程 编程、研究、Computer Use

实用的选择顺序是：

  1. 单次 LLM 调用能解决，就先不做 Agent；
  2. 步骤固定且业务规则明确，就用工作流；
  3. 必须根据环境反馈动态调整，才用自主 Agent；
  4. 高风险主干用工作流，开放式局部用自主模式。

还可以让自主 Agent 先生成工作流，再用确定性代码执行。这种混合方案同时保留了规划的灵活性和执行的稳定性。

安全不是过滤器，而是三层架构

第一章按照“被绕过的难度”把护栏分成三层：

  1. 上下文层：控制模型能看到什么，识别越狱、提示注入和不相关内容；
  2. 执行层：控制模型能做什么，通过权限、沙盒、风险评级与人工确认拦截危险动作；
  3. 数据层：控制世界最终允许发生什么，用数据库约束、行级安全等机制守住底线。

越往下，越少依赖模型自己的判断，也越难被一次提示注入穿透。同一上下文中的 Agent 很难可靠判断自己是否已被注入，因此只做输入过滤永远不够。

护栏还要同时评估两种错误：危险请求被放行，以及合法请求被误拒绝。只盯着前者，会得到一个“很安全但什么也做不了”的系统。

五个值得反复复用的设计模式

第一章最后给出了贯穿全书的五种模式，我把它们记成了一张速查表：

模式 我的理解
提议者—审核者 生成与评判分离，审核者只看产物和证据，不共享生成者的盲区
渐进式披露 先提供目录，细节按需加载，节省上下文并提高选择精度
只增不改 状态追加演进，换取可缓存、可重放、可审计
边界集 + 保留集 既验证应该改变的样本，也验证不该受影响的样本
最小 diff + 可回滚 缩小改动范围，保留来源，使错误可归因、可撤销

这五条表面上分散，其实都指向同一个目标：降低不确定性，让系统变化可以被观察、验证和撤销。

我的 Agent 开发检查清单

读完第一章后，如果要启动一个 Agent 项目，我会先回答下面这些问题：

  • 任务的“完成”由什么外部证据证明？
  • Agent 必须看到哪些信息？哪些信息不该进入上下文？
  • 它需要哪些最小工具与权限？
  • 路径可以预定义吗，还是必须动态决策？
  • 每次行动后，环境结果如何回流？
  • 最大轮数、超时和熔断条件是什么？
  • 哪些操作不可逆，必须人工确认？
  • 验证机制是否独立于被检查的 Agent？
  • 失败后能否重试、回滚或安全移交？
  • 模型、Prompt 或 Harness 改动后，如何做回归评估？

写在最后

第一章给我的最大收获，不是学会了 ReAct 这个名词，而是换了一种看待 Agent 的方式：

不要只问“模型聪不聪明”，还要问它看见了什么、能够做什么、如何知道做对了，以及做错后谁来兜底。

一个真正可靠的 Agent，不是一个永不犯错的模型，而是一套让错误可发现、可限制、可纠正的系统。模型决定能力上限，Harness 决定这些能力能否安全地落到现实世界。

第一章配套实验记录

实验1-1：chapter1-1 上下文感知 Agent 与消融实验

验证上下文组件对 Agent 行为的影响，并提供消融结果可视化。

查看完整实验记录

实验1-2：chapter1-2 Kimi 网络搜索 Agent

Kimi K3 通过多轮搜索完成来源核验，实验验收通过。

查看完整实验记录

实验1-3：GPT-5.6 Sol 深度研究（这里用qwen3.7-plus代替）

托管搜索与代码执行形成闭环，三轮交互验收通过。

查看完整实验记录

实验1-4: 文生图工作流与原生图像生成的对照

工作流与 GPT-Image 2 完成全部生成任务，Gemini 路线因环境依赖失败。

查看完整实验记录