如何构建 Agent 及其上下文工程

原文: https://www.nazha.co/posts/how-to-build-agents
整理时间: 2026-02-20

什么是 Agent？

Agent 定义

Agent 是基于 LLMs 构建的具备自我决策能力、推理、规划和与环境交互的系统。

站在巨人肩膀上：使用 Claude Agent SDK 构建 Agent

为什么是 Claude Agent SDK

优势 说明
下限保障 Claude Code / CoWork 基于 Claude Agent SDK 开发，已验证可行性
国产兼容 Minimax、GLM、DeepSeek 都有兼容 Claude Code 的专有 API
开箱即用 内置 Tools、上下文压缩、Session 管理
扩展能力强 支持 Hooks、MCP Tools、Skills 等方式扩展
官方出品 基础模型是 Claude Opus/Sonnet 时的最佳选择

长任务完成度是 Agent 的核心指标：

Opus 长任务表现

  • 完成度越高的 LLMs，在指令对齐、工具有效使用上效果更好
  • Opus 在长任务表现非常出色
  • 建议：先用 Claude Agent SDK run 起来，后续再优化

Skills 是什么

一个典型的 Skill 包含三层内容：

  1. 元数据 - 告诉 Agent 这个 Skill 是干啥的，什么时候用
  2. 指令 - 工作流程、最佳实践、注意事项（Agent 确定使用时才读取）
  3. 资源或代码 - 脚本、模板或参考文档（渐进式披露策略）

Skill 示例

Skills 的本质是「可复用的提示词」：

  • ✅ 给 LLMs 运行时上下文学习的能力
  • ✅ 动态的：执行过程中动态加载，非执行前注入
  • ✅ 方便复用
  • ✅ 依赖于 Agent 环境（非强依赖）

为什么需要动态加载？

如果把所有 Skills 放到系统提示词里：

  • ❌ Token 膨胀 - 用不上的 token 占据系统提示词大部分
  • ❌ 混淆 - 多余信息导致低质量回复

动态加载 → 原子化 → 可重用、可组合 👍

Skills vs MCP vs SubAgent

MCP (Model Context Protocol) 是连接 AI 应用与外部系统的开源标准

MCP 重点：Agent 和外部世界的数据交互

Agent 维度：以个体「人」或「角色」为维度定义

“我们不能把一个带说明书的电锯称之为木工”

—— 来自 @dotey

MCP 是连接外部系统的标准

Frontend 比喻

前端同学能听懂的比喻：

  • React 页面 = Agent
  • React Components = Skills
  • useEffect = MCP

实际设计原则：

类型 适用场景
Skills 随时变化、灵活的领域知识和工作流
Tools / SubAgent 稳定的、可靠的行为

Hooks 是什么

利用 Hooks 在 Claude Code 生命周期的不同节点插入自定义处理。

可以做的事情：

  • Log 记录
  • 通知
  • 代码格式化（如 ESLint 检查）
  • …

不适合 Claude Agent SDK 的场景

  • ❌ Claude 模型不是实现任务的最佳模型
  • ❌ 有自己更好的抽象和实现
  • ❌ 设计架构无法基于 Claude Agent SDK 实现

Multi-Agent 架构：转交 vs 委托

“一旦智能达到某个阈值，多智能体就成为提升性能的关键方式”

通过在不同上下文窗口的智能体间分配工作，增加并行推理的容量。

委托 (Delegation)

Agent as Tool - 专用 Agent 被封装为可调用的函数，供其他代理使用。

特点：

  • 缓解多 Agent 之间通信难度
  • 关注点分离 (Separation of concerns)
  • “父子”分层协作模型
  • 主 Agent 保持任务控制，调用子 Agent 处理子任务
  • 不移交任务控制权

委托模式架构

优点：架构设计简单，灵活性强

转交 (Handoff)

去中心化的多智能体编排方式，一个智能体可以将整个对话或任务委托给另一个智能体，单向转移控制权和上下文。

特点：

  • 没有单一”大脑”
  • 被转交的 Agent 完全接管与用户的互动
  • 需要维护共享内存或状态传递上下文

缺点：

  • 如果转交路径确定，灵活性较低
  • 共享上下文更难管理
  • 顺序回合增加延迟

其他 Multi-Agent 模式

模式 说明
工作流 按预定义 SOP 流程编排智能体
Swarm 多个代理作为团队解决问题，去中心化，共享信息上下文
Graph 基于确定性有向图的代理编排，包含多路径、分支、反馈循环

Swarm Intelligence

Graph patterns

公式化的 Context Engineering

传统自回归 LLM 模型

Standard probabilistic model

其中 C = prompt，但对现代系统来说，C = prompt 是不够的。

上下文工程的重新定义

将上下文 C 重新概念化为动态结构的信息组件集合 c₁, c₂, …, cₙ：

上下文工程公式

组件类型：

组件 含义
c_instr 系统指令和规则
c_know 外部知识（RAG/Web Search/记忆系统）
c_tools 可用外部工具的定义和返回
c_mem 执行累计的过程数据
c_state 多智能体系统和编排转交的数据
c_query 用户的请求

优化目标

「寻找到一组理想的上下文生成函数 F，以最大化提升 LLMs 的预期输出质量」

组装函数 A 是动态上下文编排形式：

A = Concat ∘ (Format₁, ..., Formatₙ)

知识检索是信息论最优问题：

  • 选择与目标答案在给定查询条件下具有最大互信息量的知识
  • 要求检索到的上下文不仅语义相似，且对于解决任务具有最大信息量

用户可见的上下文很少

常见问题：

  • 过程累积导致的上下文膨胀
  • 工具定义和结果大量消耗 token
  • 中间推理过程在上下文大量累积
  • Agent 执行过程中无法对齐目标，不遵循指令

上下文卸载

卸载策略

1. 卸载中间过程

Code Execution 像函数一样：

  • 有输入和输出
  • 中间过程被封装/消除
  • 不污染上下文

2. 渐进式披露

  • 将大文档拆分成小文档
  • 卸载到文件系统
  • 对 RAG 返回的候选结果进行卸载

文件系统作为上下文的容器

为什么用文件系统？

优势 说明
容量无限 不受上下文长度限制
天然持久 内容不会丢失
智能体可直接操作 模型学习按需读写文件
可逆的 内容外部化，没有被丢掉
Plan/Scratch files 创建临时文件整理思路、跟踪进度
Long context handling 旧消息压缩到文件，需要时重读

核心观点：将文件系统当作结构化的外部记忆体

基于文件系统的二次检索策略

二次检索策略

适用场景：组件文档、库文档、API 文档等偏结构性文档

传统 RAG 的问题：

  • 如果只召回描述，没召回 API
  • 或召回了 API 但没召回 Demo

二次检索步骤：

  1. 对文件做摘要处理
  2. 只把摘要文档送入 RAG 系统检索
  3. Agent 做粗略检索（5-10 个候选）
  4. 从候选中找出匹配要求的全量文档

好处：

  • 减少 Token 和上下文
  • 降低噪音干扰
  • 后续可直接本地 grep 检索，无需再次召回

从 Tools 到 Scripting

减少中间过程还可以借鉴编程中「函数」的概念：

  • 通过 Agent 自动编写和执行代码来链接操作
  • 减少中间过程的输出

参考：

自我强化

Claude Code 中的 Todo read/write 工具

作用：Todo 的读写，在读写过程中这份 Todo 会再次返回上下文，让 Agent 在长循环里持续对齐目标。

进阶：Plan 模式

面向开发环境工具分层设计

趋势：越来越多的 Agent 把宿主环境搬到 Unix/Linux 环境

原因：

  • LLMs 可直接访问文件系统
  • Bash 操作等基础功能
  • 配置了 Node.js/Python 可直接写脚本和代码

结论：标准协议（CodeAct/SQL/Shell）天然比自定义工具对 LLMs 更友好

MCP 分层设计

事实：许多流行通用智能体使用的工具数量出人意料地少

  • Claude Code: 十几个工具
  • Manus: 不到 20 个

SOTA 构建生产智能体的三基本要素

  1. 沙箱 - 让 Agent 住在沙箱上
  2. 可执行环境
  3. 文件系统

Agent 的设计原则

1. 先定义好环境还是先构建智能体？

Biomni 案例 (开源)

  • Biomni-E1: 统一行动空间的基础生物医学环境
    • 150 种专业生物医学工具
    • 105 个软件包
    • 59 个数据库
  • Biomni-A1: 专门设计用于高效利用该环境的智能代理

Biomni Overview

构建 E1 的方法：

  1. 从 25 个学科类别各选 100 篇最新论文
  2. LLM Agent 按顺序处理每篇论文
  3. 提取、复制或生成关键任务、工具、数据库和软件

A1 的设计：

  1. 使用检索系统识别最相关工具、数据和软件
  2. 基于 LLM 的推理和领域专业知识生成分步执行计划
  3. 每一步通过可执行代码表达，实现精确而灵活的组合

2. 从简开始，必要时才增加复杂性

建议路径：单智能体 → Multi-Agent

“做 Agent 设计和上下文工程的目的应该是「简化」而不是复杂化”

最佳实践来源：

  • 并非来自更多花哨的上下文管理层
  • 并非来自巧妙的检索技巧
  • 而是来自简化
  • 来自移除不必要的技巧并给予模型更多信任

经验：每一次简化系统架构，系统都会变得更快、更稳定、也更智能。

3. 动作空间的设计向训练数据看齐

上下文工程 SOTA 的最佳实践 = 「跟 LLMs 的认知对齐」

LLMs 针对全网信息训练，对已有系统、Spec、工具都非常了解。

向训练数据对齐的动作空间设计：

动作 说明
写代码 模型最擅长的能力
Bash Unix/Linux 命令行
文件读写 基础操作
命令行使用 -h 获取帮助信息

总结

构建 Agent 及其上下文工程的核心要点：

  1. 使用 Claude Agent SDK 快速起步
  2. Skills = 可复用的动态提示词
  3. Multi-Agent 选择：委托 vs 转交
  4. 上下文工程 = 动态信息组件的编排
  5. 文件系统 = 外部记忆体
  6. 简化 > 复杂化
  7. 与 LLMs 训练数据对齐

原文: https://www.nazha.co/posts/how-to-build-agents
整理: 2026-02-20