Context Engineering 和 Prompt Engineering 有什么区别？

Prompt Engineering 关注指令怎么写；Context Engineering 关注每轮推理时哪些信息应进入上下文，包括工具、历史、检索结果、记忆、约束和评测反馈。

为什么 Agent 工具越多不一定越好？

工具定义占用上下文并增加选择难度。工具边界不清、功能重叠或参数含糊，会让 Agent 选错工具、漏填参数或执行错误流程。

生产环境怎么评估 Agent 工具调用是否可靠？

构造离线评测集，覆盖自然语言任务、期望工具、期望参数和最终结果，重点检查结果是否正确，而非强行要求每次走完全相同的中间路径。

Context Engineering：AI Agent 生产化的核心不是提示词，而是上下文预算

为什么 Agent 生产化会卡在上下文上

过去做 LLM 应用，很多优化集中在提示词上：角色设定怎么写、输出格式怎么约束、示例怎么放。但 Agent 系统进入生产环境后，问题会变得更系统化。

一个 Agent 在真实任务里不只读取用户问题，还会读取系统指令、工具列表、MCP 服务描述、外部数据、历史消息、检索结果、工具返回值、记忆、错误日志、评测反馈。所有这些信息都会进入或影响上下文。

这意味着，生产级 Agent 的核心工程问题不是”提示词够不够长”，而是：如何在有限上下文窗口里放入最小但最高信号的信息。

从 Prompt Engineering 到 Context Engineering

Prompt Engineering 关注的是”怎么写指令”。它适合解决单轮分类、摘要、格式化生成等任务。

Context Engineering 关注的是”模型在这一轮推理时应该看到什么”。它覆盖的不只是 prompt，还包括：

系统指令：角色、边界、输出格式、任务目标。
工具定义：工具名称、用途、参数、返回结构、使用条件。
外部上下文：RAG 检索结果、数据库记录、API 返回值、文件内容。
交互历史：多轮对话、已完成步骤、用户偏好、失败记录。
长期记忆：任务状态、项目约定、历史决策、阶段性结论。
评测反馈：哪些工具调用有效，哪些路径会失败。

对 Agent 来说，上下文不是静态文本，而是一个持续变化的运行时状态。

核心知识结构

可以把 Context Engineering 拆成 6 个模块。

1. 上下文预算

LLM 的上下文窗口再大，也不是无限资源。上下文越长，模型越可能被低价值信息干扰。工程上应优先保留高信号内容，减少冗余工具输出、重复历史和无关检索片段。

2. 工具设计

工具不是给人看的 API 文档，而是给 Agent 使用的操作界面。工具名称要明确，参数要减少歧义，返回内容要直接服务下一步推理。

3. 检索与外部数据

RAG 不应只是”搜一批相似 chunk 塞进去”。生产 Agent 需要根据任务阶段动态决定查什么、查几次、保留哪些证据、丢弃哪些噪声。

4. 记忆与压缩

长任务会超过上下文窗口。此时需要用 compaction 压缩历史，用结构化笔记保存关键状态，而不是把所有工具调用结果一直堆在上下文中。

5. 子 Agent 分工

复杂研究、排障、信息收集任务可以拆给多个子 Agent。每个子 Agent 使用独立上下文探索一个方向，再把压缩后的结果交给主 Agent 汇总。

6. 离线评测

Agent 行为具有非确定性。生产系统不能只靠人工感觉判断效果，而要建立离线评测集，持续检测工具描述、参数设计和上下文裁剪是否引入回归。

工具不是 API，而是 Agent 的操作界面

传统 API 只要字段定义清楚，人类开发者会自己阅读文档、理解业务、判断调用时机。但 Agent 不一样。Agent 会根据当前上下文自行判断是否调用工具、调用哪个工具、如何填写参数。

一个差的工具定义通常有这些问题：

名称过于宽泛，例如 search、query、handle。
多个工具功能重叠，Agent 无法判断边界。
参数字段依赖隐含知识，例如 type、mode 没有枚举。
返回值太长，把原始 JSON、日志、HTML 全塞回上下文。
工具描述只说明”能做什么”，没有说明”什么时候不该用”。

更好的工具定义应该像这样：

{
  "name": "search_customer_refund_logs",
  "description": "Search payment and refund logs for a specific customer. Use this only when the task requires diagnosing refund, duplicate charge, or payment failure issues.",
  "parameters": {
    "type": "object",
    "properties": {
      "customer_id": {
        "type": "string",
        "description": "Internal customer ID, not email or display name."
      },
      "time_range": {
        "type": "object",
        "properties": {
          "start": { "type": "string", "format": "date-time" },
          "end": { "type": "string", "format": "date-time" }
        },
        "required": ["start", "end"]
      }
    },
    "required": ["customer_id", "time_range"]
  }
}

这里的重点不是 JSON Schema 本身，而是让 Agent 更容易判断：这个工具解决什么问题、输入应该是什么、边界在哪里。

一个可落地的上下文工程流程

生产 Agent 的上下文组织可以按下面流程设计：

解析用户任务，判断任务类型和风险等级
选择最小必要工具集，而不是加载全部工具
拉取任务相关记忆、项目约定和用户上下文
执行检索或工具调用，获取外部证据
压缩工具返回值，只保留对下一步有用的信息
生成中间状态，例如计划、待办、已验证事实
必要时拆分子 Agent，隔离大规模搜索上下文
主 Agent 汇总结果，生成最终输出
离线评测工具选择、参数填写和最终结果
根据失败样本迭代工具描述、上下文裁剪和记忆策略

这个流程的核心是：每一步都主动裁剪上下文，而不是被动等待上下文窗口爆掉。

长任务为什么需要 Compaction、Memory 和 Subagents

长任务常见于代码迁移、资料研究、复杂排障、企业流程自动化。它们可能持续几十轮甚至几百轮工具调用。

这类任务如果只靠完整历史消息，会出现 3 个问题：

1. 历史越来越长

工具输出、错误日志、检索结果会快速膨胀。即使模型支持长上下文，也会增加成本和干扰。

2. 关键状态容易丢

真正重要的不是所有历史，而是当前目标、已完成动作、未解决问题、关键决策和外部约束。

3. 分工上下文不同

一个 Agent 做所有事，会把搜索、分析、写作、验证的上下文混在一起。子 Agent 可以隔离探索过程，只把高密度结论交给主 Agent。

推荐的做法是：

机制	作用
Compaction	压缩已完成阶段，保留关键事实和未解决问题
Structured Memory	把任务状态、项目约定、重要决策写入外部记忆
Subagents	让子 Agent 独立探索，返回压缩结论或 artifact 引用

评测重点：不要只看路径，要看结果

Agent 系统的一个难点是：同一个任务，Agent 每次可能走不同路径。它可能调用不同工具、搜索不同关键词、用不同顺序完成任务。

因此，评测不应该只检查”是否完全按固定步骤执行”，而应该重点检查：

是否选择了合理工具。
参数是否完整且符合格式。
是否拿到了足够证据。
是否完成了最终状态。
是否避免危险操作。
是否在失败时可恢复。

一个简化的评测样例：

task: "Find duplicate charges for customer 9182 during April and summarize affected orders."
expected_tools:
  - search_customer_refund_logs
  - get_order_detail
expected_arguments:
  customer_id: "9182"
  time_range:
    start: "2026-04-01T00:00:00Z"
    end: "2026-04-30T23:59:59Z"
expected_outcome:
  - identifies_duplicate_charge: true
  - lists_affected_orders: true
  - avoids_unrelated_customers: true
  - provides_auditable_evidence: true

这里不强制 Agent 每次用完全相同的中间步骤，但要求最终结果可验证。

常见失败模式

工具过载

一次性暴露几十上百个工具，会让 Agent 的选择空间过大。更好的方式是按任务阶段加载工具，或者使用 tool search 延迟加载低频工具。

工具返回太长

很多系统把原始接口响应直接返回给模型，导致上下文被日志、HTML、嵌套 JSON 填满。工具层应先做摘要、过滤和结构化。

子 Agent 交接不清

如果主 Agent 给子 Agent 的任务边界太模糊，子 Agent 会重复搜索、遗漏方向，或者输出无法合并的结论。

只评测最终文本

如果只看最终回答是否流畅，会漏掉错误工具调用、参数错误、证据不足和不可恢复状态。生产评测必须覆盖工具级行为。

生产落地 Checklist

上线前至少检查这些点：

结论

Context Engineering 的本质，是把 Agent 的上下文窗口当成一种稀缺系统资源来管理。

一个可靠的生产 Agent，不是因为 prompt 更长，而是因为它在每一步都能拿到恰好足够的信息：该看的工具、该保留的记忆、该压缩的历史、该检索的证据、该验证的结果。

对工程团队来说，最实用的落地原则是：

少加载工具，多明确边界；少堆历史，多维护状态；少相信单次表现，多做离线评测；少追求万能 Agent，多设计可控上下文。

当上下文被系统化管理，Agent 才能从”能跑 Demo”走向”可维护、可观测、可迭代”的生产系统。

参考资料

Anthropic Engineering: Effective context engineering for AI agents
Anthropic Engineering: Writing effective tools for agents — with agents
Anthropic Engineering: How we built our multi-agent research system
OpenAI API Docs: Function calling
GitHub Blog: Measuring what matters: How offline evaluation of GitHub MCP Server works