从提示工程到上下文工程：写好 Agent 的秘诀

【本文是在图灵社区大模型技术共学营的演讲，Slides 链接】

深入探索 AI Agent 的设计哲学与实践策略。从 Chatbot 的对话模式到 Agent 的行动模式，系统性地设计和管理 Agent 的信息环境，构建高效、可靠的 AI Agent 系统。

Part 1: 范式变迁 - 从 Chatbot 到 Agent

从 Chatbot 到 Agent：范式的根本转变

我们正在经历 AI 交互模式的根本性转变：

Chatbot 时代

🗣️ 对话式交互：用户提问 → AI 回答 → 循环往复的问答模式
📚 知识渊博的顾问：只能”说”不能”做”，被动响应用户需求
🛠️ 典型产品：ChatGPT、Claude Chat

Agent 时代

🎯 自主行动模式：用户设定目标 → Agent 执行 → 自主规划和决策
💪 能干的助手：既能”想”也能”做”，主动发现和解决问题
🚀 典型产品：Claude Code、Cursor、Manus

Chatbot 的核心技巧：提示工程

提示工程 (Prompt Engineering) 专注于优化与 LLM 的单次对话：

🎭 角色设定：为 AI 设定专业背景
1
你是一位资深架构师...
📝 清晰指令：明确输出要求
1
用200字总结...

📖 少样本学习：提供示例指导

1 2	例子1: 输入→输出例子2: 输入→输出

💡 本质: 这些技巧都是在优化对话的质量，而非行动的效果

资料来源: OpenAI, Prompt Engineering Guide

Chatbot 的根本局限

❌ 无法行动
- 不能执行代码
- 不能访问网页
- 不能操作文件
🔄 无状态
- 每次对话相对独立
- 难以处理长期任务
- 缺乏上下文连续性
🧠 无记忆
- 无法积累经验
- 每次都”从零开始”
- 不能学习和改进
⏳ 被动等待
- 只能响应用户输入
- 不能主动发现问题
- 缺乏自主性

Part 2: Agent 核心解析

什么是 AI Agent?

定义: 一个能够感知环境、自主决策、采取行动、积累经验的 AI 系统。

核心能力：

🛠️ 工具使用 (Tool Use): 通过 API、命令行等与外部世界交互
📋 任务规划 (Planning): 将复杂目标分解为可执行步骤
🔧 错误恢复 (Error Recovery): 遇到问题能够调整策略
📚 经验学习 (Learning): 从成功和失败中积累知识

资料来源: Yao et al., “ReAct: Synergizing Reasoning and Acting in Language Models”

Agent 的核心循环：ReAct 框架

用户目标: "帮我分析这个CSV文件的销售趋势"

Agent 循环:
1. Observe (观察): 用户想要分析CSV文件
2. Think (思考): 我需要先读取文件，然后进行数据分析，最后生成可视化
3. Act (行动): 调用 read_file('sales.csv')
4. Observe: 获得CSV数据，包含月份和销售额
5. Think: 需要写个Python脚本来分析数据
6. Act: 调用 write_file('analyze.py', 'import pandas as pd...')
7. Observe: 脚本文件已创建
8. Think: 现在执行脚本来分析数据
9. Act: 调用 execute_command('python analyze.py')
10. Observe: 输出显示Q3销售额增长15%，图表已保存为trend.png
11. Think: 任务完成，需要总结发现并展示图表
12. Act: 返回分析结果："Q3销售额增长15%，详见trend.png"

观察 → 思考 → 行动 → 观察 - 这个循环让 Agent 能够持续适应和解决问题。

工具调用示例：Web Search

让我们通过一个具体的例子来理解 Agent 如何调用工具：

// 用户请求
{
  "role": "user",
  "content": "帮我搜索一下 OpenAI o3 模型的最新发布信息"
}

// Agent 决策：给用户说一句话，并调用工具
{
  "role": "assistant", 
  "content": "我来帮您搜索 OpenAI o3 模型的最新信息。",
  "tool_calls": [{
    "name": "web_search",
    "id": "toolu_01ABC123def456",
    "arguments": {
      "search_term": "OpenAI o3 model release announcement 2024",
      "explanation": "搜索 OpenAI o3 模型的最新发布信息"
    }
  }]
}

// 工具响应
{
  "tool_use_id": "toolu_01ABC123def456",
  "content": {
    "results": [
      {
        "title": "OpenAI Announces o3 Model",
        "url": "https://openai.com/blog/o3-model",
        "snippet": "OpenAI today announced o3, its latest reasoning model..."
      },
      {
        "title": "o3 Achieves Breakthrough Performance",
        "url": "https://techcrunch.com/2024/openai-o3",
        "snippet": "The o3 model demonstrates significant improvements in mathematical reasoning..."
      }
    ],
    "search_query": "OpenAI o3 model release announcement 2024"
  }
}

// Agent 继续处理，整合信息并向用户输出结果
{
  "role": "assistant",
  "content": "根据搜索结果，OpenAI o3 模型的最新信息如下：\n\n1. **发布时间**：2024年12月...\n2. **主要特性**：在数学推理方面取得突破性进展...\n3. **性能提升**：相比 o1 模型..."
}

Agent Loop 的核心实现

基于对 Claude Code 的深度分析，一个生产级 Agent 的主循环包含以下关键阶段：

            Agent Loop 执行流程图

用户输入
   │
   ▼
消息预处理 ─────┬─ Token 使用量评估
               ├─ 压缩阈值检测
               └─ 上下文验证
   │
   ▼
系统提示生成 ───── 动态生成适应当前任务的提示
   │
   ▼
会话流处理 ─────┬─ 模型配置与选择
               ├─ 流式响应管理
               └─ 中断信号处理
   │
   ▼
工具调用检测 ────┬─ 无工具调用 → 返回文本响应
               └─ 有工具调用 → 进入工具执行流程
   │
   ▼
工具执行引擎 ────┬─ 工具发现与验证
               ├─ 权限检查
               ├─ 并发控制
               └─ 结果处理
   │
   ▼
循环判断 ────────┬─ 继续循环 → 回到消息预处理
               └─ 结束循环 → 输出最终结果

工具执行的 6 阶段流水线

生产级 Agent 必须有严格的工具执行流程以确保安全性和可靠性：

阶段1: 工具发现与验证
├─ 工具名称解析
├─ 工具注册表查找
└─ 可用性检查

阶段2: 输入验证
├─ Schema 验证（如 Zod）
├─ 参数类型检查
└─ 必填参数验证

阶段3: 权限检查
├─ Allow：直接执行
├─ Deny：拒绝执行
└─ Ask：请求用户确认

阶段4: 取消检查
├─ AbortController 信号
├─ 用户中断处理
└─ 超时控制

阶段5: 工具执行
├─ 异步执行
├─ 流式结果输出
└─ 错误捕获

阶段6: 结果格式化
├─ 结果标准化
├─ 状态清理
└─ 事件记录

并发工具管理：智能调度的关键

核心问题：如何安全高效地并发执行多个工具？

// 工具的并发安全分类
const toolConcurrencySafety = {
  // 可以安全并发的工具（读操作）
  concurrent: ["read_file", "list_dir", "search", "web_fetch"],
  
  // 必须串行执行的工具（写操作）
  sequential: ["write_file", "edit_file", "run_command", "delete_file"]
};

关键设计原则：

✅ 读操作可以安全并发
⚠️ 写操作必须串行执行
⚡ 动态调度以优化性能

工具系统的未来：从”使用工具”到”制造工具”

现状: Agent 的工具集是开发者预先定义好的，是静态的。

未来: Agent 能够自主进化其工具集。

技术路径：

MCP (Model Context Protocol): 标准化的上下文协议，让工具开发变得简单
自动工具生成: 当 Agent 遇到新问题时，能够：
1. 搜索开源代码: 在 GitHub 等平台寻找相关实现
2. 自动封装: 将找到的代码封装成 MCP 工具
3. 测试验证: 在沙箱环境中测试新工具
4. 持久化复用: 将有效的工具加入工具库供未来使用

意义: 这将让 Agent 从被动的工具使用者，变成主动的工具创造者，极大扩展其能力边界。

MCP (Model Context Protocol) - 工具开发的标准化

什么是 MCP？

Model Context Protocol 是 Anthropic 推出的开放协议，用于标准化 LLM 与外部数据源和工具的连接方式。

核心特性：

标准化接口 - 统一的工具定义格式
语言无关 - 支持 Python、JS、Go 等
即插即用 - 简单的服务器/客户端模式
安全隔离 - 内置权限和沙箱机制

MCP 工具示例：

// MCP 服务器定义
const server = new MCPServer({
  name: "weather-service",
  version: "1.0.0"
});

// 注册工具
server.tool({
  name: "get_weather",
  description: "获取指定城市的天气",
  parameters: {
    location: { type: "string" }
  },
  handler: async ({ location }) => {
    // 实际的天气 API 调用
    return await fetchWeather(location);
  }
});

资料来源: Model Context Protocol Documentation

主流模型工具调用

Claude Sonnet 4 的革命性设计

关键创新：Special Token 而非 XML

使用特殊的 token 序列来标记工具调用，带来的优势：

无需转义：代码、JSON、特殊字符可以直接传递

解决了什么问题：

# 传统 XML/JSON 方式需要转义
{"code": "print(\"Hello, World!\")"}  # 引号需要转义

# Claude 的 special token 方式
<tool_use>print("Hello, World!")</tool_use>  # 直接传递

为什么重要：在处理代码生成、复杂数据结构时，避免了大量转义错误

资料来源: Anthropic Docs, Tool Use

Gemini 2.5 Pro：多模态的原生集成

核心优势：

原生谷歌搜索: 可将 Google Search 作为一个内置工具直接调用。模型可以自主判断何时需要实时信息，并自动执行搜索，返回带有来源引用的可验证结果。
多模态输入: 可以直接将图片、短视频、音频、甚至大型 PDF 文档作为输入，模型能够原生理解这些内容
长文档处理: 能够直接处理长达 2M tokens 的文档，包括 PDF、Word 等格式

独特能力示例：

from google import genai
from google.genai import types

client = genai.Client()
with open("report_2024.pdf", "rb") as f:
    pdf_data = f.read()

prompt = "请分析这份年度报告的营收趋势"
response = client.models.generate_content(
    model="gemini-2.5-pro",
    contents=[
        types.Part.from_bytes(
            data=pdf_data,
            mime_type='application/pdf',
        ),
        prompt
    ]
)
# Gemini 原生理解 PDF 中的：
# - 文字、图表、表格
# - 布局和格式
# - 无需文本提取！

资料来源: Google AI Docs, Document Processing

Claude 的革命性能力：Computer Use

定义: 这不是一个简单的工具，而是赋予 Agent 直接操作一个完整、隔离的 Linux 虚拟电脑环境的能力。

核心能力：

文件操作: read_file('data.csv'), write_file('analysis.py', 'import pandas as pd...')
命令执行: run_command('python analysis.py'), run_command('ls -l | grep .csv')
GUI 操作: 截屏、点击、输入文本、操作应用程序
完整环境: 拥有文件系统、网络、进程管理等完整的操作系统能力

工作流程：

提供工具和提示
- 添加 computer use 工具到 API 请求
- 用户提示：”保存一张猫的图片到桌面”
Claude 决定使用工具
- 评估是否需要桌面交互
- 构造工具调用请求
执行并返回结果
- 提取工具输入（screenshot/click/type）
- 在虚拟机中执行操作，返回执行结果
循环直到完成
- Claude 分析结果
- 继续调用工具或完成任务

支持的操作：

📸 截屏捕获
🖱️ 鼠标控制（点击、拖拽）
⌨️ 键盘输入
🖥️ 命令执行

计算环境要求：

沙箱隔离: 专用虚拟机或容器，安全边界保护
虚拟显示: 推荐分辨率 1024x768, 1280x720 或 1920x1080（必须严格遵守，否则鼠标点击坐标可能不准确）
操作处理器: 截屏捕获、鼠标动作模拟、键盘输入处理

Agent 循环实现示例：

while True:
    # Claude 请求工具使用
    response = client.messages.create(...)
    
    # 提取并执行动作
    for action in response.tool_calls:
        result = execute_action(action)
        
    # 返回结果给 Claude
    if task_complete:
        break

安全考虑：

敏感操作人工确认
操作日志审计
提示注入防护

革命性意义:

将 Agent 从一个”API 调用者”提升为了一个”程序员”和”数据分析师”
能够完成过去无法想象的端到端复杂工作
真正实现了”给 AI 一台电脑，让它自己解决问题”的愿景

资料来源: Anthropic Docs, Computer Use

Agent 的演进方向：独立的虚拟操作系统

现状的局限: 当前 Agent 大多被限制在一个浏览器标签页或一个临时的 Shell 实例中，这是”单线程”的，无法处理需要持久化状态和多应用协作的复杂任务。

演进方向：每个 Agent 都应该拥有一个专属的、隔离的、持久化的虚拟操作系统环境。

在这个环境中，它可以:

并行处理多任务: 像人类使用电脑一样，同时打开和操作多个应用窗口（Terminal, Browser, IDE, 文件管理器）
自由切换上下文: 在不同任务窗口间无缝切换，管理每个任务的独立状态和历史
拥有持久化文件系统: 保存工作成果，管理项目文件，安装新的软件
网络通信能力: 与其他 Agent 或服务进行交互

这是 Agent 向着更强大能力演进的必然方向。

Model as Agent：通过 RL 实现能力跃升

基于 Kimi-Researcher 的实践，Agent 能力的真正突破来自于端到端的强化学习训练：

传统方法的局限：

工作流系统：依赖手工设计的多智能体协作，难以适应环境变化
**模仿学习(SFT)**：受限于人类演示数据，难以处理长期任务

端到端 RL 的优势：

整体优化：规划、感知、工具使用等能力一起学习
自适应：自然适应工具和环境的变化
探索学习：通过大量探索发现最优策略

实践成果：Kimi-Researcher 通过 RL 训练，从 8.6% 提升到 26.9% 的准确率，平均执行 23 个推理步骤，探索超过 200 个 URL。

资料来源: Kimi-Researcher: End-to-End RL Training for Emerging Agentic Capabilities

工具设计的核心原则

💡 核心理念：让模型利用预训练知识，降低学习 prompt 的难度

1️⃣ 正交性 (Orthogonality)

每个工具解决独立问题，避免功能重叠
✅ 好的例子：
- search_web search_knowledge_base - 明确区分搜索范围
- text_browser visual_browser - 明确区分处理方式
❌ 差的例子：
- search_google search_milvus - 暴露底层实现
- browse_url browse_page - 功能重叠不清

2️⃣ 描述性命名 (Descriptive Naming)

名称直接反映功能，利用模型的语言理解能力
✅ 好的例子：
- web_search_agent phone_call_agent - 清晰表明功能
- execute_code read_file - 动词+名词结构
❌ 差的例子：
- daisy ivy - 抽象代号，无法理解功能
- sw exec - 过度缩写
工具的描述需要清晰、无歧义
描述工具的限制（例如：电话只能打国内号码）

3️⃣ 贴近常见用法 (Familiar Patterns)

参数符合开发者直觉
文件操作像 Unix 命令
搜索像 Google API

4️⃣ 让 Agent 自主处理错误

工具调用出错时返回详细错误信息，让 Agent 决定下一步
利用 SOTA LLM 的编程能力
❌ 差的例子：Phone Call Failed
✅ 好的例子：Phone Call Failed: failed to initiate call: phone number format error

这些原则让模型能够利用预训练时学到的知识，减少学习新工具的成本。

Multi-Agent 架构：突破单一 Agent 的局限

基于 Anthropic Research Feature 的实践：

为什么需要 Multi-Agent？

单 Agent 的局限：

💰 上下文窗口成本高昂
⏱️ 顺序执行效率低下
📉 长上下文质量下降（”lost in the middle” 问题）
🧠 无法并行探索

Multi-Agent 的优势：

✅ 并行处理多个子任务
✅ 独立上下文窗口
✅ 总体性能提升
✅ 适合开放式研究任务

架构示意：

用户查询
    │
    ▼
Lead Agent（协调者）
    │
    ├─→ 分析任务
    ├─→ 创建 SubAgents
    │
    ├─→ SubAgent 1（独立搜索）
    ├─→ SubAgent 2（独立搜索）
    └─→ SubAgent 3（独立搜索）
         │
         ▼
    结果聚合 → 最终报告

关键设计：

压缩即本质
- 每个 SubAgent 在独立上下文中探索
- 提炼最重要的 tokens 返回
- Lead Agent 综合多源信息
注意 Token 用量，别刷爆信用卡了
- 单聊天：1×
- 单 Agent：4×
- Multi-Agent：15×
- 价值必须匹配成本
适用场景
- ✅ 信息收集类任务
- ✅ 多角度分析需求
- ✅ 任务容易并行

资料来源: Anthropic, How we built our multi-agent research system

SubAgent 架构：控制上下文长度的关键策略

当任务复杂度增加时，主 Agent 的上下文会迅速膨胀，导致：

成本增加：每个 token 都需要付费
延迟增加：更长的上下文意味着更慢的响应
质量下降：过长的上下文会导致 “lost in the middle” 问题

SubAgent 提供了一种优雅的解决方案：

主 Agent
    │
    │ 将复杂任务委托给 SubAgent
    ▼
SubAgent（独立上下文）
├─ 只包含任务相关信息
├─ 不继承主 Agent 的历史
├─ 完成后只返回结果摘要
└─ 主 Agent 上下文保持精简

SubAgent 的核心价值：

上下文隔离：每个 SubAgent 有自己的干净上下文
成本控制：避免重复传递无关历史信息
并行能力：多个 SubAgent 可以同时处理不同任务
结果聚合：只将关键结果返回主 Agent

典型应用场景：

分析不同模块的代码
并行处理多个独立任务
执行需要大量上下文的专项工作

深入 Agent 的对话流：思考的显式化

user: "帮我查一下今天旧金山的天气，然后根据温度推荐我穿什么。"

A:
  thinking: "用户有两个请求：1. 查天气；2. 根据天气推荐穿着。
            我需要先调用天气API，然后基于结果给出建议。"
  text: "好的，我来帮您查询旧金山的天气情况。"
  tool: get_weather(location="San Francisco")

tool: 
  content: {"temperature": "15°C", "condition": "Sunny", "wind": "15km/h"}

A:
  thinking: "15°C加上15km/h的风，体感会更凉。需要防风保暖。"
  text: "旧金山今天晴朗，15°C，有风。建议穿长袖+防风外套。"

关键实现细节：

思考过程显式化：让 Agent 的推理过程可见可调试
工具调用时机：在明确需要外部信息时才调用
结果解释：不只是展示数据，而是给出解释和建议

Part 3: 上下文工程 (Context Engineering)

上下文工程的核心理念

“The context is the agent’s operating system.” - Manus

定义: 系统性地设计和管理 Agent 的信息环境，使其能够高效、可靠地完成任务。

为什么重要：

上下文决定了 Agent 能”看到”什么 👁️
上下文决定了 Agent 能”记住”什么 🧠
上下文决定了 Agent 能”做到”什么 💪

上下文信息的来源

1. 文档化的团队知识

技术文档、API 文档、设计文档
会议记录、决策记录、项目计划
代码注释、commit message、PR 描述

2. 结构化的项目信息

任务管理系统的数据
代码仓库的结构和历史
测试用例和测试结果

3. 动态的执行环境

当前的系统状态
实时的日志和监控数据
用户的即时反馈

策略一：围绕 KV 缓存进行架构设计

核心问题: Agent 的输入输出比例极度不平衡（100:1）

解决方案: 最大化 KV 缓存命中率

最佳实践：

稳定的提示前缀: 系统提示保持不变
1
System: You are a helpful assistant...

Append-only 上下文: 只追加，不修改

1 2	messages.push(newMessage) // 不要修改已有消息

确定性序列化: JSON key 顺序固定

{
  "name": "...",
  "age": "...",
  "city": "..."
}

缓存友好的工具输出: 格式统一，减少变化

策略二：上下文压缩 - 不得已的选择

核心原则：在成本和延迟允许的情况下，能不压缩就不压缩。

压缩是一个权衡：

好处：减少 token 使用，降低成本
代价：损失信息细节，可能影响任务质量

基于 Claude Code 的实践，只有在接近上下文限制时才触发压缩：

8段式结构化压缩模板：

1. 背景上下文 (Background Context)
   - 项目类型和技术栈
   - 当前工作目录和环境
   - 用户的总体目标

2. 关键决策 (Key Decisions)
   - 重要的技术选择和原因
   - 架构决策和设计考虑

3. 工具使用记录 (Tool Usage Log)
   - 主要使用的工具类型
   - 文件操作历史

4. 用户意图演进 (User Intent Evolution)
   - 需求的变化过程
   - 优先级调整

5. 执行结果汇总 (Execution Results)
   - 成功完成的任务
   - 生成的代码和文件

6. 错误与解决 (Errors and Solutions)
   - 遇到的问题类型
   - 解决方法

7. 未解决问题 (Open Issues)
   - 当前待解决的问题
   - 已知的限制

8. 后续计划 (Future Plans)
   - 下一步行动计划
   - 用户期望的功能

压缩时机的选择：

优先使用 SubAgent 来控制上下文长度
其次考虑清理无关的历史信息
最后才使用压缩算法

策略三：TODO List - 智能任务管理系统

## 当前任务状态（实时更新）
- [x] 项目初始化
- [x] 依赖安装  
- [ ] 实现用户认证 ← 当前进行中
  - [ ] 设计数据库模式
  - [x] 创建 API 端点
  - [ ] 前端集成
- [ ] 部署到生产环境

TODO 系统的核心价值：

对抗遗忘：在长对话中保持目标清晰
进度可视化：用户和 Agent 都能看到进展
优先级管理：自动排序（进行中 > 待处理 > 已完成）
子任务分解：复杂任务自动分解为可执行步骤

智能排序算法：

1
2
3

// 状态优先级：in_progress(0) > pending(1) > completed(2)
// 重要性优先级：high(0) > medium(1) > low(2)
// 相同优先级按创建时间排序

策略四：错误即学习机会

传统做法 vs 正确做法：

❌ 传统做法：隐藏错误，重试

1
2
3

Action: npm install
// Error hidden
Action: npm install (retry)

✅ 正确做法：保留完整的错误上下文

Action: npm install
Error: npm ERR! peer dep missing: react@^18.0.0

Thinking: 需要先安装正确版本的 React
Action: npm install react@^18.0.0
Success: Dependencies installed

原理: 错误信息帮助 Agent 更新其世界模型，学习环境的约束和依赖关系。

策略五：6 层安全防护体系

基于 Claude Code 的企业级实践：

第1层：输入验证
├─ Schema 验证（如 Zod）
├─ 参数类型强制检查
└─ 边界约束验证

第2层：权限控制
├─ Allow：直接执行
├─ Deny：拒绝执行
└─ Ask：用户确认

第3层：沙箱隔离
├─ 命令执行沙箱
├─ 文件系统限制
└─ 网络访问控制

第4层：执行监控
├─ AbortController 中断
├─ 超时控制
└─ 资源限制

第5层：错误恢复
├─ 异常捕获
├─ 自动重试
└─ 降级处理

第6层：审计记录
├─ 操作日志
├─ 安全事件
└─ 合规报告

每一层都为 Agent 的安全执行提供保障，确保即使在复杂环境中也能稳定运行。

策略六：动态提醒注入 (System Reminder)

在关键时刻自动注入上下文提醒：

<system-reminder>
检测到您正在修改认证相关代码。
请注意：
1. 密码必须加密存储
2. 使用 bcrypt 或 argon2
3. 实现速率限制防止暴力破解
</system-reminder>

触发条件：

TODO 列表状态变化
检测到特定操作模式
错误模式重复出现
安全相关操作

这种动态注入机制让 Agent 在关键时刻获得额外的指导，避免常见错误。

策略七：并行采样 (Parallel Sampling) - 质量与效率的平衡

通过多个独立的推理路径并行探索，然后选择或综合最佳结果：

用户问题
    │
    ├─→ Agent 实例 1：探索路径 A
    ├─→ Agent 实例 2：探索路径 B
    └─→ Agent 实例 3：探索路径 C
         │
         ▼
    结果验证与选择
    ├─ 一致性检查
    ├─ 质量评分
    └─ 最佳答案选择

应用场景：

复杂问题的多角度分析
需要高可靠性的关键决策
探索性任务的并行尝试

实现要点：

使用不同的初始提示或温度参数
设置合理的并行度（通常 3-5 个）
建立有效的结果评估机制

策略八：顺序修订 (Sequential Revision) - 迭代优化

让 Agent 对自己的输出进行反思和改进：

1	初始响应 → 自我评估 → 识别问题 → 生成改进 → 最终输出

修订提示示例：

请审视你刚才的回答：
1. 是否完全解决了用户的问题？
2. 是否有遗漏的重要信息？
3. 是否有可以优化的地方？

基于以上反思，请提供改进后的答案。

最佳实践：

限制修订轮次（通常 2-3 轮）
提供具体的改进维度
保留修订历史便于学习

资料来源: Thinking in Phases: How Inference-Time Scaling Improves LLM Performance

上下文工程的设计哲学：极简设计，最大能力（Alita）

核心理念：

**最小预定义 (Minimal Predefinition)**：
- 避免过度设计和预设
- 保持系统的灵活性
- 让 Agent 根据任务需求自适应
**最大自我进化 (Maximal Self-Evolution)**：
- 通过学习和经验积累能力
- 动态适应新的任务类型
- 持续优化执行策略

实践启示：

不要试图预先定义所有可能的场景
给 Agent 足够的灵活性去探索解决方案
简单的架构往往比复杂的系统更有效
“简单即是终极的复杂”

Part 4: 记忆与知识系统

三层记忆架构：从短期到长期

基于 Claude Code 的实践，一个成熟的 Agent 需要三层记忆体系：

┌─────────────────────────────────────────────────────┐
│               短期记忆层                            │
│   当前会话上下文 (messages[])                       │
│   • User Message                                    │
│   • Assistant Message                               │
│   • Tool Results                                    │
│   • System Prompts                                  │
│                                                     │
│   特征：O(1)查找，实时访问，自动Token统计            │
└─────────────┬───────────────────────────────────────┘
              │ 接近上下文限制时触发
              ▼
┌─────────────────────────────────────────────────────┐
│               中期记忆层                            │
│   8段式结构化压缩                                   │
│   • 背景上下文     • 执行结果                       │
│   • 关键决策       • 错误处理                       │
│   • 工具使用       • 未解决问题                     │
│   • 用户意图       • 后续计划                       │
│                                                     │
│   特征：智能压缩，上下文连续，大幅节省Token          │
└─────────────┬───────────────────────────────────────┘
              │ 持久化存储
              ▼
┌─────────────────────────────────────────────────────┐
│               长期记忆层                            │
│   持久化知识系统（CLAUDE.md / Knowledge Base）       │
│   • 项目上下文     • 开发环境                       │
│   • 用户偏好       • 安全配置                       │
│   • 代码风格       • 工作流程                       │
│                                                     │
│   特征：跨会话恢复，用户定制，项目持续记忆           │
└─────────────────────────────────────────────────────┘

User Memory - 个性化的关键

定义: Agent 记住特定用户的偏好、历史和上下文

存储内容：

用户偏好：”我喜欢简洁的代码风格”、”避免使用 class 组件”
项目上下文：”我们使用 React 18 + TypeScript”、”API 使用 GraphQL”
历史决策：”上次我们选择了 PostgreSQL 而非 MySQL”、”使用 pnpm 管理依赖”

实现机制：

向量数据库存储
相似度检索
动态注入到系统提示

资料来源: Survey on Building Agentic RAG Systems

Knowledge Base - 集体智慧的结晶

定义: 所有用户和 Agent 交互中积累的可复用知识

内容类型：

解决方案模板: “如何配置 Nginx 反向代理”
最佳实践: “Python 项目的标准结构”
问题模式: “这类错误通常是因为…”

知识生命周期：

捕获：Agent 成功解决问题
提炼：提取通用模式
存储：结构化保存
复用：相似问题直接应用

资料来源: 01.me, Agent 如何从经验中学习

总结：上下文工程的核心要点

“The context is the agent’s operating system.”

核心洞察：

范式转变：从对话到行动
- Chatbot → Agent
- 提示工程 → 上下文工程
Agent 四大能力
- 🛠️ 工具使用 (Tool Use)
- 📋 任务规划 (Planning)
- 🔧 错误恢复 (Error Recovery)
- 📚 经验学习 (Learning)

八大实践策略：

KV 缓存优化 - 架构设计的核心
智能压缩 - 8段式结构化模板
TODO 系统 - 智能任务管理
错误学习 - 保留完整错误上下文
安全防护 - 6层防护体系
动态提醒 - 关键时刻注入
并行采样 - 质量与效率平衡
顺序修订 - 迭代优化输出

技术要点总结：

智能压缩机制：只在必要时压缩，优先使用 SubAgent
并发工具管理：读操作并发，写操作串行
三层记忆架构：短期、中期、长期记忆协同工作
Model as Agent：通过端到端 RL 训练实现能力跃升
工具设计原则：正交性、描述性、贴近常见用法
Multi-Agent 架构：突破单一 Agent 的局限

🚀 The future is agentic. Let’s build it with well-designed context.

文件内容的智能注入机制

用户提及文件 → 系统自动检测
       │
       ▼
    路径解析与验证
    ├─ 安全检查
    ├─ 权限验证
    └─ 文件存在性
       │
       ▼
    智能容量控制
    ├─ 限制文件数量
    ├─ 控制单文件大小
    └─ 管理总体容量
       │
       ▼
    内容格式化注入
    ├─ 语法高亮
    ├─ 行号显示
    └─ 相关性排序

这种智能注入机制确保 Agent 能够高效地访问相关文件内容，同时避免上下文过载。

加入 Pine AI

我们正在寻找能够构建 SOTA autonomous AI Agent 的全栈工程师。

我们秉持的理念：每个人对公司估值的贡献都要在千万美元以上

加入 Pine AI 的要求

🤖 1. 熟练使用 AI 编程

80%+ 代码通过人机协作完成
代码面试：AI 辅助下 2 小时完成功能开发
内部系统全部基于 AI 构建

💻 2. 热爱动手解决问题

“Talk is cheap, show me the code”
成为架构师和产品经理的结合体
直接指挥 AI，减少信息损耗

🏗️ 3. 扎实的软件工程能力

完善的文档和测试
让 AI 能理解和维护代码
高质量的工程实践

🧠 4. 理解 LLM 原理

了解基础原理和能力边界
驾驭 LLM 的正确方法
提供合适的上下文和工具

🚀 5. 解决世界级难题的信心

追求 SOTA 水平
与初创公司共同成长
不断超越现有水平

🎯 我们的使命

通过构建能与世界实时交互、从经验中学习的 Agent，真正为用户解决烦恼，办成事。

让用户逐步建立信任，最终将重要任务交给 Pine。

Pine AI - Building Agents That Get Things Done

1	mail -s "Join Pine AI" -A /path/to/your_resume.pdf boj@19pine.ai

元信息：这份 Slides 的创作过程

这份 Slides 本身就是人机协作的产物，正是上下文工程在实际应用中的体现。

初稿由 AI 生成，基于提供的参考资料
人类提供方向、结构和关键洞察
AI 负责展开、组织和润色
多轮迭代，不断完善

【本 Slides 使用 Slidev 制作。原始 Slidev Markdown】