摘要、压缩与处理大工具输出的工程实践

摘要、压缩与处理大工具输出的工程实践——从 Manus 的经验，看 Context Engineering 的“高风险区”

引言：压缩的不可逆风险与工程对策

上下文压缩是AI Agent工程中的高风险操作——它是有损且不可逆的。一旦关键信息在压缩过程中丢失，系统将无法恢复，可能导致后续决策链条的全面偏差。

Manus联合创始人Peak Ji提出的核心方法论：高质量的摘要不是让模型"写摘要"，而是让模型"填表格"；处理大工具输出不是无脑透传，而是场景化的策略选择。这一工程实践为我们提供了确保信息保真度的系统化路径。

第一部分：高质量摘要的秘诀——从创作到抽取

1.1 错误做法：开放式指令的不可控性

"请总结以下内容..."

核心问题：

• 信息覆盖不确定：模型可能遗漏工程师认为关键的信息
• 输出稳定性低：相同输入多次调用结果不一致
• 下游可解析性差：自然语言输出难以被程序消费
• 错误定位困难：无法精确知道"哪里漏了"

1.2 正确做法：Schema约束的信息抽取

定义结构化表单，让AI精确填充字段：
​
┌─────────────────────────────────────────┐
│              Task Summary               │
├─────────────────────────────────────────┤
│ 用户原始目标        │ [必须] 原文核心诉求  │
│ 当前子目标          │ [必须] 当前聚焦任务  │
│ 已修改文件          │ [可选] 文件路径列表  │
│ 已做关键决策        │ [必须] 决策+理由     │
│ 当前阻塞点          │ [必须] 无/具体问题   │
│ 下一步明确行动      │ [必须] 可执行步骤    │
└─────────────────────────────────────────┘

范式转移的本质：

Schema的工程价值：

• 显式编码业务知识：哪些信息对系统决策至关重要
• 建立确定性契约：工程师与模型之间的可靠接口
• 支撑版本化迭代：业务变化时Schema显式变更，变更可追溯

第二部分：处理大工具输出的双策略

当工具返回海量Token时， "完整返回"与"即时处理"存在根本张力。Peak提出场景化的策略选择框架。

2.1 策略选择的决策边界

开始
  │
  ├── 工具输出经预处理后长度 < 阈值（如4K tokens）？
  │   └── 否 → 强制预摘要或子Agent封装（策略二）
  │   └── 是 → 继续判断
  │
  ├── Agent需要立即处理（非暂存备用）？
  │   └── 否 → 立即卸载到文件系统，返回指针
  │   └── 是 → 策略一：先完整返回 + 保险措施
  │
  └── 信息时效性高（延迟处理会贬值）？
      └── 否 → 考虑批量异步处理
      └── 是 → 确认策略一

关键认知：策略一的"完整返回"是有边界的，不是无脑透传原始输出。

2.2 策略一：简单搜索——先完整返回，必须加保险

适用条件（三者缺一不可）：

• 工具输出经预处理后长度可控（< 4K tokens）
• Agent极有可能立即处理
• 信息时效性高

三层过滤机制：

Layer 1: 工具层预处理（必须）
├── 爬虫：只取正文，去广告/导航/页脚
├── 搜索：只取Top-K（如10条），非全部1000条
└── 数据库：分页+字段筛选，非SELECT *
​
Layer 2: 策略决策
└── 预处理后长度 < 阈值 → 进入策略一
​
Layer 3: 系统级压缩（未来时刻）
└── 原始结果 → 压缩为指针（但关键洞见已保险持久化）

保险措施：对冲"延迟压缩"的不确定性

风险场景：
  完整返回 → Agent还未处理 → 系统提前压缩（因窗口压力）→ 信息丢失
​
保险机制：
  完整返回 → Agent立即提取洞见 → 主动write工具写入文件
              └── 即使原始信息被提前压缩，洞见已安全
​
关键设计：指示模型"立即提取并持久化关键认知"，而非保存完整原文

保险措施的写入内容：

2.3 策略二：复杂搜索——子Agent作为工具

适用场景：

• 需要多次查询并整合信息
• 输出经预处理后仍超长
• 复杂性超出主Agent即时处理能力

架构设计：

主Agent上下文（干净、高效）
├── 调用：advanced_search("AI Agent上下文工程最新进展")
│       ↓
│   ┌─────────────────────────────────────┐
│   │         子Agent（独立工作流）         │
│   │  • 自主决定搜索策略（多源、多轮）      │
│   │  • 内部完成整合、去重、验证           │
│   │  • 输出：固定Schema的结构化结果        │
│   └─────────────────────────────────────┘
│       ↓
└── 接收：{热点话题, 关键数据, 趋势判断, 信息来源}
​
效果：主Agent上下文极其干净，复杂性完全封装

策略对比：

第三部分：关键工程决策——为何简单搜索不立即卸载

3.1 两种模式的成本对比

3.2 工程决策原则

核心权衡：

• 效率优先：简单搜索的即时性价值高于卸载的安全性
• 风险对冲：保险措施（主动写入）弥补压缩时机的不确定性
• 场景分离：复杂任务用子Agent封装，简单任务用策略一快速处理

第四部分：与WSCI框架的融合

Manus实践与LangChain WSCI框架的深度对应：

关键洞察：保险措施本质是在Compress之前preemptively执行Write，确保关键信息在压缩发生前已安全持久化。

结语：工程智慧的本质

Peak Ji的方法论揭示了AI Agent工程的核心原则：

1. 摘要不是创作，是抽取 —— 用Schema约束确保保真度
2. 压缩有风险，主动写入来对冲 —— 用机制设计防丢失
3. 场景决定策略 —— 没有银弹，只有权衡
4. 复杂性要封装 —— 子Agent隔离，主Agent保持干净
5. 效率与安全的平衡 —— 即时性价值高时，用保险措施对冲风险

这些"充满权衡的工程智慧"，正是从Demo走向生产系统的关键能力。

结语：真正的难点不在技术，而在取舍

摘要、压缩、大工具输出，本身都不复杂。 真正难的是：

Manus 的经验给了我们几个极其重要的原则：

1. 摘要不是创作，是抽取 —— 用Schema约束确保保真度
2. 压缩有风险，主动写入来对冲 —— 用机制设计防丢失
3. 场景决定策略 —— 没有银弹，只有权衡
4. 复杂性要封装 —— 子Agent隔离，主Agent保持干净
5. 效率与安全的平衡 —— 即时性价值高时，用保险措施对冲风险

当 Agent 从 Demo 走向生产系统， Context Engineering 本身，就成了一门架构设计学。

参考资源

1. Manus技术分享（Peak Ji）：摘要、压缩与处理大工具输出的技巧
2. LangChain Context Engineering Best Practices
3. 《上下文工程：构建高性能AI Agent的系统性架构设计》