工具与上下文管理

工具系统设计

Tool Use / Function Calling 机制

Agent 的工具调用遵循标准的 Function Calling 协议：

1. 模型推理：LLM 根据当前上下文决定需要调用哪个工具
2. 结构化输出：模型生成符合 JSON Schema 的工具调用请求
3. 执行引擎：Harness 解析请求、校验参数、执行工具
4. 结果注入：工具输出被注入回上下文，供下一轮推理使用

用户输入 → LLM 推理 → 工具调用请求（JSON）→ 执行 → 结果注入 → LLM 继续推理

工具类型

类别	工具	用途
文件 I/O	read_file	读取文件内容（支持行号范围）
	write_file / create_file	创建或覆写文件
	edit_file / search_replace	精确编辑文件片段
Shell	bash / run_in_terminal	执行任意 shell 命令
搜索	glob / search_file	按文件名模式搜索
	grep / grep_code	按内容正则搜索
	search_codebase	语义化代码搜索
浏览器	browser_navigate, browser_click	控制浏览器进行交互
网络	fetch / fetch_content	获取网页内容或 API 响应

工具设计原则

1. 原子化（Atomic）

   • 每个工具做一件事，做好一件事
   • read_file 只读、write_file 只写，不混合

2. 可组合（Composable）

   • 复杂操作通过组合简单工具实现
   • 例：grep_code 找到位置 → read_file 读取上下文 → search_replace 修改

3. 明确的输入输出 Schema

   • 每个工具都有严格的 JSON Schema 定义
   • 参数有类型约束、必填标记、描述说明
   • 模型通过 Schema 理解工具的能力和约束

4. 描述驱动（Description-Driven）

   • 工具描述是模型决策的唯一依据
   • 好的描述 = 准确的工具选择

---

上下文管理

Context Window 限制与挑战

Context Window 是 Agent 最稀缺的资源：

挑战	说明
容量有限	即使 200K token，面对大型代码库也远远不够
注意力衰减	模型对中间位置的信息关注度较低（"Lost in the Middle"）
成本线性增长	token 越多，推理成本越高、延迟越大
噪声干扰	无关信息越多，推理质量越差

上下文压缩策略（Context Compression）

当上下文接近窗口限制时，系统会执行压缩：

1. 摘要替换（Summarization）

   • 将早期的详细对话替换为精简摘要
   • 保留关键决策和结果，丢弃中间过程

2. 工具输出截断（Output Truncation）

   • 大文件只保留相关行
   • 长命令输出只保留关键部分

3. 选择性遗忘（Selective Forgetting）

   • 已完成的子任务细节可以安全移除
   • 只保留结果和关键经验

4. 滑动窗口（Sliding Window）

   • 保留最近 N 轮交互的完整上下文
   • 更早的交互逐步压缩

Skill 按需加载机制

Skill 是预定义的能力模块，不在初始 prompt 中加载，而是按需激活：

• 触发条件：用户意图匹配、关键词触发、Agent 主动请求
• 加载方式：将 Skill 的 prompt 和工具集动态注入当前上下文
• 卸载时机：任务完成后从上下文中移除，释放空间

这是知识"按需加载，不前置"原则的具体体现。

子 Agent 的上下文隔离

当任务过于复杂或上下文即将溢出时，主 Agent 会生成子 Agent：

• 隔离：子 Agent 拥有独立的上下文窗口，不占用主 Agent 空间
• 聚焦：子 Agent 只接收与子任务相关的最小上下文
• 通信：通过结构化消息（邮箱机制）与主 Agent 通信
• 合并：子 Agent 完成后，只将最终结果（非完整过程）返回主 Agent

---

我的理解与思考

（在此记录你对工具系统和上下文管理的理解、疑问和延伸思考）