KEEL · 龙骨 · A CURRICULUM FOR THE AI ERA
Context Engineering — keel 龙骨
Agent 的上下文是一次模型调用的工作集，不是数据库，也不是完整运行日志。它有容量上限，有来源和优先级，还要和工具协议、权限、状态恢复一起工作。本课程从一个“第二十轮为什么突然答错”的现场开始，逐步做出可解释的上下文管线。
Agent 的上下文是一次模型调用的工作集，不是数据库，也不是完整运行日志。它有容量上限，有来源和优先级，还要和工具协议、权限、状态恢复一起工作。本课程从一个“第二十轮为什么突然答错”的现场开始，逐步做出可解释的上下文管线。
章节目录
- 01. 上下文窗口究竟限制了什么？ — 支付服务的事故诊断已经运行到第二十轮。用户问的是“服务恢复了吗，和上次事故有关吗”，模型却突然回答：“请提供工单号。”日志显示，INC-42 明明在第六轮出现过，程序也保存了全部消息。
- 02. Token 怎样被可靠测量？ — 上一章得到 127 个动态预算，但这个数字只有在计数可信时才有意义。支付服务诊断里出现了中文工单、英文日志、JSON 工具参数和工具 schema；如果统一使用“字符数除以四”，误差可能刚好把一次请求推过边界。
- 03. Token 预算应该分给谁？ — 现在我们知道动态空间还有 127 个教学 token。接下来的争议通常比计算更困难：安全团队说系统规则不能删，工具团队说 schema 必须完整，产品要求带最近二十轮对话，检索系统返回十段历史事故，模型还需要生成结构化结论。
- 04. 预算不足时先保留什么？ — 预算计划告诉我们“还能放 127 个 token”，却没有回答应该放什么。支付事故当前有五份候选：用户目标、最新监控、两周前事故、一条工具调用和它的结果。如果空间只够其中三份，简单保留最新消息可能把工具调用与结果拆开，也可能丢掉用户最初要求的证据约束。
- 05. 选择仍然放不下时怎样 Compaction？ — Selector 已经拒绝低价值候选，但支付事故的活动历史仍然超过预算。现在不能再靠“少选几条”解决，因为最近消息里包含未决问题，旧消息里又包含事故开始时间和证据 ID。系统需要改变表示方式：这就是 Compaction。
- 06. 工具轨迹为什么不能随便压缩？ — 普通对话删掉一条旧消息，最多让语义变差；工具轨迹删错一条，下一次请求可能直接违反供应商消息协议。
- 07. Compaction 何时触发，重启后怎样恢复？ — 支付事故的上下文从 60% 增长到 81%，系统开始压缩。摘要已经生成，worker 却在保存新消息前崩溃。队列随后重投同一个任务：它应该再次摘要旧历史，还是识别出上一轮已经完成？
- 08. 怎样证明 Context 策略真的更好？ — 新策略把支付事故输入从 6120 tokens 压到 3810，节省了 38%。这只能证明字符串更短，不能证明 Agent 更好。如果摘要漏掉“订单仍然失败”，模型可能错误宣布服务恢复；如果保留了结论却丢掉 INC-42，回答看似正确却无法审计。
- 09. 完成一个有预算、可恢复的事故诊断 Agent — 结课项目把前八章放回同一条 Harness 运行。目标不是再写一个孤立的 summarize() 函数，而是让系统能够回答：模型本轮看到了什么、为什么没看到另一条材料、压缩改变了什么、工具轨迹是否合法、worker 重启后从哪里继续，以及质量收益是否值得。