AI 阅读打卡 Day 2

Agent = LLM + 上下文 + 工具

Agent三大件，LLM是大脑，上下文是眼睛，工具是手脚。

LLM: Agent的整个决策内核，理解意图、思考规划、做出判断。不仅像是人家大脑的神经元集合，还是经验塑造的思维方式， LLM的能力也来自两部分：预训练所积累的世界知识与语言能力，以及后训练所固化的决策策略-----后者具体技术（如监督微调和强化学习）
上下文: 不只是输入给模型的文本，还是Agent每个决策点收到并保留的信息表单---来自环境的观察，用户记忆，领域知识，自身状态和任务进展
工具: Agent用来感知或改变外部世界的接口，包括工具定义、调用协议和适配器---从预定义的工具调用到动态生成代码，从委托子Agent协作到主动与用户沟通。

工具：Agent 的手脚

工具是agent与外部世界交互的桥梁：感知类工具承载环境到agent的观察，执行类工具承载agent到环境的行动。

感知工具让 Agent 能访问信息：搜索引擎提供实时网络数据，文件系统读取本地文档，API 和数据库则对接外部服务和企业核心数据。

执行工具让 Agent 改变世界：代码执行、文件操作、系统命令、外部 API 调用——决策由此变成实际行动。

协作工具让 Agent 与其他 Agent 分工合作：委托子 Agent 完成专项任务，在关键决策点请求人类确认，或在多 Agent 系统中协调行动。

事件触发工具与前三类在调用方式上有本质的区别——它们不是 Agent 主动调用的，而是作为外部输入来驱动 Agent 开始执行任务。

比如收到一封新邮件、到了某个预定时间点、或另一个系统发出了 Webhook 回调，这些事件会激活 Agent，让它开始后续的思考和行动。

事件适配器同样是 Environment 向 Agent 提供观察的通道，因此本书把它归入广义的工具体系。

工具调用（Tool Calling，也称Function Calling）是现代LLM Agent的一项核心能力，它让模型能够通过结构化的方式调用外部工具。

这种能力将LLM从一个纯粹的文本生成器转变为能够执行实际操作的智能系统。

工具调用的流程分为四步：首先，在上下文理告诉模型有哪些宫欧可用；然后，模型自主判断要不要调用工具、调用哪个、传什么参数；接着，工具执行完毕后，结果被追加到上下文总；最后，模型据此决定下一步行动，这个循环就是ReAct的基础。

以一个查询天气的场景为例，四步流程在API层面的简化表示如下：

第一步：声明工具
tools: [{
    name: 'get_weather',
    parameters: {
        city: 'string',
    }
}]

第二步：模型决定调用
assisant: {
    tool_calls: [{
        function: 'get_weather',
        arguments: {
            city: 'shanghai'
        }
    }]
}

第三步： 结果追加到上下文
tool: {
    tool_call_id: "call_1",
    content: {
        temperature: 25,
        sky: '晴天',
    }
}

第四步： 模型基于结果回复
assisant: {
    content: '上海的天气是晴天，气温25度'
}

工具设计的核心原则是：通过基础能力用于组合与探索；专用工具用于约束高风险和强业务规则操作

LLM：Agent 的大脑

模型即 Agent：当模型本身成为产品。 Agent 的学习机制：从上下文适应到持久更新

Agent的行为如何发生改变？

任务内适应:
主要载体是当前上下文（示例•状态•检索结果）更新特性：即时、低成本任务结束后不自动保留
外部制品更新:
主要载体是知识•指令•程序（文档•Prompt/Skill•Harness）更新特性：跨任务持久、可审计依赖检索或工具调用
模型参数更新:
主要载体是模型权重， SFT•偏好训练•RL 更新特性：高维能力、广泛泛化。训练与回归成本较高

上下文：Agent 的眼睛

上下文是Agent在每个决策点能看到的全部信息，就像一个人在做决策时需要看到桌上摊开的所有资料----任务说明、参考手册、之前的沟通记录、最新的数据

Agent的上下文窗口就是它的事业，从API的视角看，每次调用LLM时的上下文由以下五个部分构成：

系统提示词 System Prompt: 与用户每次输入的提示词不同，系统提示词由开发者编写，在整个对话过程中保持不变，相当于Agent的岗位说明书---定义他的身份、权限和行为准则。通过提示工程精心设计系统提示次，我们可以塑造Agent的工作方式。系统提示词中还会包含跨会话保存的用户记忆和动态注入的环境状态。
工具定义 Tool Definitions: 声明Agent可用工具的名称、功能描述和参数格式。没有工具定义，Agent就无法识别和调用任何工具，但他不会因此停下来----消融实验会说明这一点。工具定义与系统提示词一起构成对话中保持不变的静态前缀。
用户消息 User Messages: 来自用户输入、用户消息中还可能包含通过RAG动态检索引入的外部支持----覆盖训练数据截止后的信息或私有领域知识
模型回复 Assisant Messages: 模型之前生前的回复，最多包含三个部分----思考过程、文本内容和工具调用请求。在一次具体的回复中，三者不一定同时出现：例如Agent决定调用工具时通常只有reasoning + tool_calls, 给出最终回复时则只有content+reasoning.
工具执行结果 Tool Results: Agent框架执行工具后返回的结果。这些结果是Agent下一步思考的直接依据，也让它能够从执行结果中学习、避免重复犯错

前两项是静态前缀，后三项是随交互不断增长的动态消息历史。这五个部分共同构成了LLM每次推理时的上下文。

要验证每一个组件是否都不可或缺，最直接的方法是消融实现 Ablation Study: 就像医生每次诊断时逐一排除病因----先去掉A组件看系统是否还正常，再去掉B组件，以此类推，从而判断每个组件的贡献。

ReAct 循环

ReAct 循环就是将LLM、上下文和工具串联起来的核心机制

Agent执行任务的核心模式叫做ReAct（Reasoning + Acting）。

每一次调用LLM时，接受的完整山西该问由静态前缀和轨迹2个部分组成，所以Agent的上下文 = 静态前缀 + 轨迹。

先看最小运行骨架。它说明的是机制如何运行：Model 只负责决定下一步，Harness 负责组装上下文、校验并执行工具，Environment 负责产生真实状态变化和观察。

大概步骤如下：

用户搜索一个月的比特币走势
思考：需要搜索实时数据，再用代码分析
第一轮：调用web_search
得出结果
带着观察结果继续下一轮， ReAct循环， Res API路径： Harness闭环执行
第二轮：调用code_interpreter
最终输出: 技术分析

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

Agent = Model + harness

Harness = 上下文管理 + 工具接口 + 约束 + 验证 + 纠正

Harness不是模型之外的一切，而是边界内、模型外的运行和治理层

本章小结

本章从实践出发，建立了理解和构建 AI Agent 的基础框架。

Agent = 大脑 + 眼睛 + 手脚：LLM 是大脑（决策核心），上下文是眼睛（决定它能看到什么），工具是手脚（决定它能做什么）。三者缺一不可。

扩展眼睛和手脚是最主要的能力杠杆：在模型固定时，重新定义或扩展观察空间与动作空间——也就是扩展上下文和工具——往往能直接把原本不可解的任务变为可解。 Manus 和 OpenClaw 的演进都说明，通用性很大程度上来自接口边界的扩大；这种扩大必须按需进行，并配合权限控制和验证。

眼睛（上下文）是决定性的因素：上下文由静态前缀（系统提示词 + 工具定义）和动态轨迹（消息历史）构成。消融实验表明，各组件并不等价：去掉工具定义或工具执行结果会直接夺走行动与闭环能力，去掉另外两者的代价则取决于信息能否从当前观测重建。ReAct 循环的本质是通过不断追加轨迹来让模型持续推进任务。

Harness 是竞争力所在：模型能力正在商品化，真正的差异在于 Harness——围绕上下文和工具构建的约束、验证与纠正机制，确保 Agent “可靠地做事”。在生产级的 Agent 系统中，Harness 的绝大部分代码都在实现这些保障机制，而不仅仅是上下文和工具本身。

从工作流到自主 Agent：先优化提示词，再考虑工作流，最后才引入自主 Agent——这是降低意外风险最实用的顺序。每种编排模式都有其适用场景，不存在通用最优解。

五个设计模式贯穿全书：提议者—审核者、渐进式披露、只增不改、边界集 + 保留集、最小 diff + 可回滚。

安全是架构问题：安全问题从第一行代码就要考虑，而不是上线前打补丁。护栏按被绕过的难度分为上下文层、执行层与数据层三层，后续各章的安全讨论都挂在这个骨架上。