引言

在 AI Agent 热潮中，模型本身已相当强大，Claude、GPT 等已能完成复杂任务。真正决定成功与否的，是 上下文管理 与 工作流设计。本文基于 Greg Isenberg 的观点，结合架构师的经验，对常被忽视的关键点进行深度剖析，并提供实践建议。

1. Context Window——Agent 的核心瓶颈

• 定义：模型在执行任何操作前必须读取的全部信息。相当于 Agent 的“阅读材料”。
• 容量限制：不同模型的上下文窗口大小不同（如 GPT‑4‑turbo≈128k tokens），超出会导致截断、信息丢失。
• 质量决定输出：噪声、冗余信息会占用窗口，削弱关键指令的权重。

架构师洞察

1. 分层上下文：将长期不变的业务规则、公司专有信息放入 Skill（按需加载），只在运行时注入当前任务的短上下文。
2. 上下文压缩：使用结构化数据（JSON、YAML）而非自由文本；对历史对话进行摘要后再注入。
3. 窗口监控：在每次调用前计算预计 token 数，超出时自动裁剪或拆分任务。

2. Agent.md 的误区

传统做法把所有信息写入 agent.md，导致每次对话都要加载数千行，消耗上万 token。

为什么是浪费？

• 大多数通用知识模型本身已经掌握（如 React 用法、代码阅读技巧）。
• 重复加载同一段信息会显著降低响应速度。

架构师建议

• 仅存专有信息：公司内部流程、业务规则、机密数据。
• 使用 Skill 替代：将功能性逻辑、外部 API 调用封装为 Skill，按需加载，保持 agent.md 轻量。

3. Skill：真正的解锁钥匙

架构实现路径

1. 定义 Skill 接口：声明 name, description, parameters。
2. 实现业务逻辑：使用外部服务（数据库、搜索引擎）时，封装在 Skill 中。
3. 注册与调用：在主 Agent 中仅引用 Skill 名称，运行时自动加载。

4. 迭代式 Skill 构建流程

1. 手动跑通完整工作流，记录每一步的输入输出。
2. 标记成功/失败点，分析上下文是否足够。
3. 在同一次对话中实时纠正，让 Agent 记住修正策略。
4. 完成后让 Agent 自动生成 Skill 文件（Skill.md），并提交到代码库。
5. 持续迭代：每次失败都记录为新的单元测试，确保不会复现。

5. Sub‑Agent 与组织规模

• 逐步扩展：从单一 Agent → 多 Skill → 多 Sub‑Agent，避免“一口气”部署大量子系统。
• 资源隔离：不同业务线使用独立 Sub‑Agent，防止上下文相互污染。

6. 实践 checklist（架构师视角）

• 评估模型的上下文窗口大小，设定安全阈值（如 80%）。
• 将业务规则抽象为配置文件，放入 Skill 中。
• 实现 context_estimate(tokens) 函数，动态裁剪。
• 为每个 Skill 编写单元测试，用真实数据跑通。
• 使用版本化的 Skill 目录（skills/v1/...），便于回滚。
• 定期审计 agent.md，确保仅保留不可公开的专有信息。

结语

Context Window 是 AI Agent 成败的根本，合理的上下文管理、精简的 agent.md 与强大的 Skill 系统相结合，才能让 Agent 在复杂企业场景中发挥最大价值。希望本文能为你在构建可靠、可扩展的 AI Agent 系统时提供清晰的方向。