面向人工智能代理的高效上下文工程
《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怎么“看”数据。
✅ 立即行动清单（今天就能做）
- 检查你的系统提示：能删掉50%吗？
- 去掉所有工具的冗余输出字段
- 把“请仔细分析”换成“请用 tool_get_logs() 找最近3条错误”
- 引入
NOTES.md或压缩机制对抗长对话崩溃 - 用
head,grep,ls替代load_full_file()
最终真理：
AI不是不懂，是看太多。
优秀的上下文工程师，不是信息富翁，而是信息节制者。
原文出处：Anthropic Applied AI Team, 2025
https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
标签：无