为什么上下文越长,系统提示词越没用?

本章导读(你在这)
  ↓
① 先看一眼真实的一次运行    ← 一次任务两条关键日志
  ↓
② 先明确:长上下文不是靠后权重大
  ↓
③ Zod 契约 + 完整快照      ← 一、二
  ↓
④ 稳定 JSON + 会话状态     ← 三、四
  ↓
⑤ 系统提示只管"什么时候用" + Nag 计数  ← 五、六
  ↓
⑥ 当次注入 + 副作用标签     ← 七、八
  ↓
⑦ 失败不破坏旧快照 + 离线证明  ← 九、十
  ↓
⑧ 运行 + 实验 + 差异        ← 十一~十四
  ↓
⑨ 小结                     ← 三句话 + 七条 + 边界 + 自测

模型调用 todo_write 后,工具把整份 TODO 以 tool result 回填,消息历史里从此就有了一份「最新进度」——这就是模型的显式记忆。

请求1  模型连续调用工具(读文件)            陈旧计数 0→1
请求2  模型又调工具,没提交快照            陈旧计数 1→2
请求3  模型又调工具,没提交快照            陈旧计数 2→3
请求4  beforeModel: 计数已到 3 → 注入提醒,清零   ← 第 4 次请求看到提醒
       模型看到提醒 → 调 todo_write 提交快照

Transformer 根据内容动态计算注意力,不能简单理解为「后面 token 一定比前面重要」。但长任务有三个现实问题:

• 工具输出不断增长,早期目标要与更多内容竞争注意力;
• 相似日志和局部错误反复出现,模型更围绕眼前问题继续生成;
• 最初计划只描述「要做什么」,却没持续提供「做到哪一步」。

系统提示写「不要忘记计划」只能表达原则,不能保存任务状态。本章思路:把计划变成结构化状态,通过工具结果把最新快照放回消息流。

没有 todo_add/update/remove 三组增量接口,只有一个整体替换工具。完整快照更适合模型:

• 当前状态只由最后一次成功调用决定,易解释和重放;
• 不需要处理「更新一个已不存在的索引」的状态机;
• tool result 本身包含后续推理需要的全部计划;
• 校验完成后只一次赋值,失败不产生半更新状态。

第一步完成后,模型不能只提交「第一项已完成」,要再次提交三项完整状态。

content: z.string()
  .transform(c => c.trim())
  .pipe(z.string().min(1, "todo content must not be empty")),
status: z.enum(["pending","in_progress","completed"]),

如果直接对原字符串 min(1)," " 会通过长度检查。先 trim 再验证,它会稳定失败。两层 .strict() 都拒绝未知字段。最多 50 项。

TodoTracker 不能做成模块级单例,否则同进程创建两个 Agent 时,第二个会话会看到第一个的计划。组合根在每次 buildAgent() 时 new 一个 tracker,同一个实例既提供工具 handler,也作为工具轮观察者传给 Loop。

进程退出后状态消失,本章不做磁盘持久化(第 12 章项目 Task 才解决跨会话持久化)。

一个 assistant 消息可含多个 tool call。同一轮读三个文件,提醒计数应增加一次不是三次。规则三条:

1. 没有工具调用,不计数;
2. 本轮只要出现 todo_write,计数归零;
3. 本轮有工具但没 todo_write,计数加一。

达到 3 后,beforeModel() 返回一条 system guidance 并立即清零。注意「达到三轮」和「注入提醒」不是同一个请求:

Loop 调用模型前读取 guidance,只用于构造当前 ModelRequest,没有 push 进 history:

messages: [systemMessage(prompt), ...history, ...observerGuidance]

好处:提醒靠近当前生成位置能发挥提示作用;不会永久堆积,后续请求不会看到一串过期 reminder。

recordToolRound 在所有 tool result 配对写入历史后才记录工具名——位置不能乱移,否则会打断 OpenAI 消息协议。

模型提交非法状态(status:"working"),路径是:JSON.parse → schema.safeParse 失败 → invalid_arguments → handler 未调用 → #todos 引用和值都不变。

状态赋值只有一个入口,只接收经 Zod 验证的输入,没有回滚问题。测试还保存更新前的数组引用,确认失败后仍是同一个快照对象。

todo_write 的 effect 是 "write"(改变会话内状态),但第 3 章审批规则精确匹配 write_file 和 edit_file,不是粗暴拦截所有 write effect。所以更新 TODO 不弹磁盘写入审批,但仍过统一权限决策并写审计。

Set-Location 'F:\笔记\Agent实操\code'
npm ci
npm run test:ch05

 Test Files  14 passed (14)
      Tests  109 passed (109)

那行 配置错误: Missing required settings: ... 仍是被断言的预期输出(config.test.ts 验证缺配置时 CLI 返回退出码 2),不是失败。

npm run ch05 -- --prompt "先建立完整 TODO，再读取 README.md 并总结运行和验证步骤"
# stderr 有 [Hook]/[Permission];模型是否先调 todo_write 取决于模型本身,
# 系统提示是引导,不是强制门控。不调就把 prompt 写更明确。

npm run ch05 -- --prompt "先用 todo_write 建立三项计划，然后原样告诉我 todo_write 返回的完整文本"
# 模型复述出整份 {"todos":[...]},中文是 \uXXXX 形式

npm run agent-tutorial -- run --chapter 5 --prompt "先建立完整 TODO，再读取 README.md 并总结运行和验证步骤"

1. 模型提交 3 项计划,下一次只提交 1 项,另外 2 项会怎样?
2. 为什么快照要输出 编写 而不是直接输出中文?
3. TodoTracker 做成单例 export const 会出什么问题?至少说两个。
4. 一条 assistant 消息里有 3 个工具调用,计数加几?
5. 提醒在第几次模型请求出现?为什么不是第 3 次?
6. 在 result.history 里能搜到 Keep the TODO list current 吗?为什么?
7. todo_write 的 effect 是 write,为什么不弹审批框?审计里有东西吗?