《Context Engineering 101》——让AI代理在有限注意力下高效行动

🔑 核心洞见

AI代理不是靠“更好提示”变聪明，而是靠“更精炼上下文”活下去。
LLM的注意力是有限资源（n²复杂度），不是无限记忆。上下文 ≠ 所有信息，而是“最值得看的那几行”。

🔄 上下文工程 vs 提示工程

维度提示工程上下文工程
目标写好一条指令管理整个推理状态
范围单次输入多轮+工具+历史+外部数据
关键问题“该怎么说？”“该让AI看到什么？”
✅ 上下文工程是提示工程的自然演进：当任务变长，提示不够了。

⚠️ 为什么必须管好上下文？

  • 注意力衰减：上下文越长，模型越记不住关键信息（“context rot”）
  • 算力限制：Transformer需计算所有token对之间的关系 → n²爆炸
  • 训练偏差：模型主要见过短上下文，长序列表现下降
  • 边际收益递减：加1000个token≠提升10%性能，很可能拖垮推理
💡 模型没有“内存”，只有“瞬时焦点”。你是它的编辑，不是信息搬运工。

🧱 有效上下文的四个支柱

1. 系统提示：黄金平衡点

  • ❌ 不要：硬编码 if-else 逻辑（脆弱）
  • ❌ 不要：模糊口号如“请聪明地做”（无信号）

  • ✅ 要：清晰、结构化、最小必要

    使用 <instructions>, <tools>, <output_format> 等标签组织
    举例：“请用get_user_data(id)获取用户，再用check_eligibility(...)判断资格”

2. 工具设计：信息要“轻、准、独”

  • 工具输出必须token高效（别传全文件，传JSON摘要）
  • 功能不重叠（人类分不清，AI更分不清）
  • 输入参数具体明确（避免 input: data → 改为 input: user_id: str）

3. 示例（Few-shot）：用“picture”代替“rulebook”

  • ❌ 别塞50个边缘case
  • ✅ 选3–5个典型、多样、具代表性的例子
  • 示例 = 让AI“看到你想要的结果长什么样”

4. 动态检索（Just-in-Time）：别提前塞，按需召唤

  • 不把10GB数据库扔进上下文 → 改用文件路径、查询ID、链接
  • AI用工具（如 grep, head, search_db）现场取数据

  • ✅ 人类式思维：不记全文，靠索引、命名、目录找信息

    🎯 Claude Code 做到：不载入大文件，只读 head -n 5 + grep "function"

🕰️ 长任务应对三法

方法适用场景机制
压缩（Compaction）长对话/多轮交互每隔几步，让AI自动生成摘要，丢弃冗余工具输出
结构化笔记（Agentic Memory）迭代开发、长期任务AI写 NOTES.md，存外部，后续重新读入
子代理架构复杂研究/多线程分析主代理指挥，子代理各攻一域，只返回精华摘要

✅ Claude Code 实战：

  • 前置：CLAUDE.md（核心目标）
  • 动态：glob, grep, bash 按需探索代码库
  • 记忆：自动保存变更日志与TODO
    → 上下文保持<5K token，完成万行代码迁移

🏁 总结：上下文工程三原则

原则说明
最小高信号只保留对当前决策最有用的token
动态而非静态信息应“被召唤”，而非“被灌输”
结构胜于体量清晰的文件结构 > 10万token堆砌
🔮 未来趋势：模型越强，人类干预越少 → 但上下文管理永远是核心杠杆。
你的任务不是喂数据，而是教AI怎么“看”数据。

✅ 立即行动清单（今天就能做）

  1. 检查你的系统提示：能删掉50%吗？
  2. 去掉所有工具的冗余输出字段
  3. 把“请仔细分析”换成“请用 tool_get_logs() 找最近3条错误”
  4. 引入 NOTES.md 或压缩机制对抗长对话崩溃
  5. 用 head, grep, ls 替代 load_full_file()

最终真理：

AI不是不懂，是看太多。
优秀的上下文工程师，不是信息富翁，而是信息节制者。

原文出处：Anthropic Applied AI Team, 2025

https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

标签：无

评论已关闭