正文
GLM-5.2 的 1M context 很适合处理长代码库、多轮工具调用和跨文档任务，但它不会自动把长任务变成可靠任务。真实失败往往不是窗口太小，而是 Agent 把无关搜索结果、重复日志和已过期计划持续带进下一轮，最后既耗时又无法判断该信任什么。
把上下文当作一个有预算的工作区，而不是无限聊天记录。任务开始时写清目标与边界；工具调用后保留结论而不是完整噪声；会话中断后从可审查的账本恢复；模型或网关不可用时从已验证的阶段重试。这套方法同样适用于使用 GLM-5.2 的 API、vLLM 服务和兼容 Agent 客户端。
1M context 解决了什么，没有解决什么
GLM-5.2 的公开部署配方标注了 1,048,576 token context，并面向工具调用和 Agent 场景。它能减少“刚读完仓库又忘了前面文件”的情况，但下面这些问题仍然存在：
| 问题 | 大窗口不能自动解决的原因 | 需要保留的工程动作 |
|---|---|---|
| 工具输出爆炸 | 长日志和重复搜索依旧占用注意力与推理时间 | 截断原文，保留错误签名、路径和结论 |
| 修改范围扩大 | 模型读得更多，不代表更知道哪些文件不能改 | 在任务账本中声明允许与禁止目录 |
| 会话中断 | 服务重启、超时或人工暂停不会自动留下状态 | 每个阶段结束写可恢复摘要 |
| 质量不可回归 | 上下文越长，越难复现某次判断依据 | 固定任务样本、记录输入版本和验证结果 |
| 成本与延迟漂移 | 可容纳不等于应当每次都塞满 | 给每个阶段分配上下文与工具调用预算 |
从任务账本开始，不从“读完整仓库”开始
每个长任务先写一份放在会话外部的账本。它可以保存在 issue、任务系统或未提交的本地文件中，但不应包含 API Key、生产日志和客户数据。
agent_task:
goal: "修复订单导出接口的权限绕过"
allowed_paths:
- "src/orders"
- "tests/orders"
blocked_paths:
- ".github"
- "infra/production"
- "secrets"
acceptance:
- "普通用户不能下载其他租户订单"
- "现有管理员导出测试仍通过"
current_phase: "locate"
evidence:
- "suspect file: src/orders/export.ts"
next_action: "trace tenant id propagation"这份账本只保存下一轮真正需要的状态：目标、范围、验收条件、已经确认的证据与下一动作。它比把几百轮自然语言原样重放更稳定，也方便人在必要时审查 Agent 将要做什么。
工具输出只保留能改变决策的部分
长任务里最容易污染上下文的是全仓搜索、测试失败和构建日志。每次工具调用后先判断结果属于哪一类：
- 证据：确定的文件、调用关系、错误签名、测试名称或可复现命令。
- 结论：例如“租户校验只在 HTTP 层存在，服务层可被后台任务绕过”。
- 噪声：重复的匹配行、无关依赖警告、完整的打包输出和已处理的失败日志。
将证据和结论写回账本，噪声不再带入下一阶段。对必须保留的原始日志，保存文件路径、生成时间与哈希，而不是把整段文本长期塞进会话。
工具输出摘要
- 失败签名：ForbiddenError: tenant mismatch
- 首次出现：tests/orders/export.test.ts:84
- 相关调用：src/orders/export.ts -> assertTenantAccess()
- 排除项：node_modules 中的同名匹配不参与本次修复在阶段边界压缩上下文
不要等到接近模型最大窗口才做压缩。长任务完成一个明确阶段时就生成摘要，例如完成“定位”“设计”“修改”“验证”中的任一阶段。压缩后的内容应能让一个全新会话继续工作：
| 阶段 | 要留下的内容 | 不应保留的内容 |
|---|---|---|
| 定位 | 根因假设、涉及文件、排除过的分支 | 完整目录树与所有搜索命中 |
| 设计 | 备选方案、选定方案、风险和验收标准 | 已废弃方案的长篇讨论 |
| 修改 | 变更文件、关键 diff 原因、尚未完成项 | 每一次编辑尝试的逐字记录 |
| 验证 | 实际执行命令、结果、失败签名与下一步 | 重复通过的完整测试输出 |
压缩前先把关键判断交给人确认，尤其是权限、数据库迁移、删除、依赖升级和线上配置。模型可以帮你汇总，但不应替你扩大授权范围。
会话中断后怎样恢复
恢复会话时，不要直接把旧聊天记录全部交给新模型。先加载任务账本、当前代码版本和最近的阶段摘要，然后要求 Agent 做一次只读复核：确认工作区状态、列出尚未完成的验收条件、说明下一条命令为何必要。
请只读取当前工作区与任务账本。
先确认已经修改的文件和未完成的验收条件。
不要编辑、安装依赖、执行迁移或访问网络。
给出下一项最小验证动作及其预期结果。恢复后的首个动作应该是低风险验证，例如查看 git diff、运行一个已有的窄测试，或确认环境变量是否存在。不要在缺少状态的情况下直接让 Agent 继续批量修改。
给模型与网关准备回退路径
长任务一定会遇到限流、超时、工具失败或模型服务短暂不可用。回退策略应按阶段设计，而不是把一个失败的长会话无限重试：
请求失败
-> 记录模型、时间、阶段和错误签名
-> 保存当前任务账本与阶段摘要
-> 重试一次同模型的最小只读动作
-> 仍失败时切换已验证的候选模型或恢复人工处理
-> 重新执行该阶段的验证，不复用未经检查的旧输出fallback 不应绕过权限、数据处理规则或测试门槛。更换模型后，允许修改的目录、审批要求和验收标准保持不变。
GLM-5.2 服务化时关注的两个资源点
vLLM 的 GLM-5.2 配方标注最低版本为 0.23.0，并列出 1M context 与 fp8_e4m3 KV cache 选项。部署时不要把“模型支持 1M”理解为每个请求都要开放 1M：并发数、KV cache、输入长度与输出长度共同决定显存、吞吐和尾延迟。
先将服务分为两类请求：短任务走较小上下文预算，只有确实需要跨仓库或跨文档推理的任务才允许进入长上下文队列。为两类请求分别记录排队时间、输入 token、输出 token、工具调用次数和失败率，才能发现某个 Agent 是否在无意义地吞掉上下文。
一次长任务的验收标准
当下面几项都成立时，长任务才算被可靠地交付：
- 目标、允许范围和验收条件在任务账本中可见。
- 每个阶段只带入必要的证据与结论，原始大日志可追溯但不反复注入。
- 会话重启后，新 Agent 能先复核状态再继续，而不是重新猜测。
- 所有代码改动有 diff、窄测试与人工审查结论。
- 服务故障时能保存状态并从同一阶段恢复，而不是把未验证输出直接带进下一步。
1M context 的价值是让 Agent 可以看见更多相关事实，不是让它永久保存所有对话。把上下文、权限和验收一起治理，GLM-5.2 才会从“能跑很久”变成“长任务仍可控”。