Lesson 09 · 练习

练习 1（设计实验）：窗口极限压力测试

v5 在 8k 下峰值仅 837——余量巨大。把窗口压到多小它才断？

import tempfile
from research_assistant import steering
from eval_agent.harness_runs import run_full_longhaul
for limit in (8000, 4000, 2000, 1200):
    steering.set_db_path_for_test(tempfile.mktemp(suffix=".db"))
    try:
        r = run_full_longhaul(workspace_base=tempfile.mkdtemp(),
                              memory_base=tempfile.mkdtemp())
        # 注：run_full_longhaul 的主窗 limit 目前固定 8k——给它加 window_limit
        # 参数透传 main_ledger 是本题第一步
        print(limit, r["main_peak_tokens"], r["presence"])
    except Exception as e:
        print(limit, "断了：", type(e).__name__)

给 run_full_longhaul 加 window_limit 透传后扫参：主窗真正的下限由哪一项决定（提示：结论累积 + 目录 + 三层 system——谁是刚性成本）？
主窗逼近下限时，哪个机制该先介入——压缩（对结论层动手？违反分层可压性！）还是「结论也外置、窗口只留最近 N 条+指针」？设计后者并说明它其实是什么（提示：把 L06 指针协议用到结论上——外置化吃掉自己的尾巴）。
由此回答：v5 的架构极限在哪？什么样的任务规模（几百源？）需要引入「分层合成」（子代理的结论再交中层子代理汇总）？

练习 2（设计实验）：矩阵的第七指标——改道响应延迟

矩阵六指标缺「改道后多快生效」。定义：从 submit_instruction 到第一个受影响决策的源数差。

在 run_full_longhaul 里埋测量点并给五档补这一列（A-D 档为「不支持」）。
E 档的延迟由安全点密度决定（L07 练习 4）。把安全点从「每源之间」改为「每 3 源之间」，重测延迟与开销的变化。
讨论：这一指标对什么场景是一票否决的（提示：安全事件响应 vs 周报调研）？矩阵指标该不该分场景加权——给「资讯调研」和「合规审计」各写一组指标权重。

练习 3（综合设计）：把 v5 骨架移植到你自己的项目

选你手头一个真实的 LLM 应用（或 kb-qa），做移植评估：

画出它的「窗口构成四桶」——先记账：哪一桶是大头？和本课程的 75-95% 工具结果结论一致吗？
八机制里挑收益/成本比最高的两个先落地（提示：通常是账本〔纯测量零风险〕+ 整形〔纯代码无损〕），写出各自的验收标准（模仿本课程「机械可测」的口径——省略必须显式怎么测？）。
哪些机制对你的场景是过度设计？写出「不做」的理由（架构决策的一半是决定不做什么）。

练习 4（思考）：课程收口——五个预算的统一账

课程九到十一共建了五层预算：步数（agent-ops L01）、轨迹钱包（L02）、时段钱包（ambient L07）、人的注意力（ambient L04）、窗口空间（本课程）。

给五层各写一行：稀缺资源 / 失控形态 / 刹车机制 / 触发后的降级动作。
五层会打架吗？举一个具体冲突（提示：时段预算说「今天还能跑」，窗口账本说「这任务装不下」——谁听谁的？）并给出仲裁原则。
用一句话向非技术同事解释这门课：为什么「更聪明的模型」解决不了这五个问题里的任何一个？