Agent 系统先收紧上下文预算和传感器

看 Martin Fowler 那篇 Fragments: July 13，最先冒出来的词不是模型分数，而是 Harness Engineering。退修里已经有人把讨论放到上下文和传感器上了，这件事很像一条正在成形的工程纪律：Agent 先要把输入收紧，再谈动作展开。

上下文窗口大了，约束反而更要短

文里有个很直白的细节：有人把 agents.md 控到 200 行以内。这个数字看着像洁癖，实际是在给工程装预算。上下文窗口确实越做越大，可窗口变大只代表能塞进更多内容，不代表模型会更稳地抓住该抓的部分。模型通常只盯住上下文里的一小块，剩下的内容即便都在，也可能只是陪跑。

这就是长文档最容易出的毛病。规则越多，真正重要的约束越容易被噪音盖住；说明越长，越容易把边界写成背景，把背景写成边界。把文件压短，不是为了写起来省事，而是逼着约束变得可见、可读、可执行。Agent 面对的不是一堆材料，而是一份有限的操作契约。

传感器要压成少量可用信号

另一个变化是，讨论开始往 computational sensors 上移。这里的传感器不是简单埋点，也不是把日志再喂给模型一遍，而是把运行时状态压成少量稳定信号。传感器一旦变成原始输出回放，输入就会再次膨胀；真正有价值的做法，是先把现场切成几条清楚的状态，再决定哪些细节交给人，哪些细节交给工具。

文里提到从 Python 转向 Rust 这类更强控制力的语言，也是在这个语境里看才顺。重点不在语言偏好，而在控制力。传感器需要的不是“能跑”，而是边界明确、异常语义明确、资源消耗明确。信号只要不稳定，模型再强也只是在抖动输入上做判断。

harness 先收口动作链

这类讨论一旦走到这里，harness 就不再像壳，更像收口器。它负责决定哪些东西进上下文，哪些东西留在外面；哪些状态可以被模型依赖，哪些状态必须通过工具再确认。上下文预算、传感器设计、权限边界、回退路径，最后都会压到这层上。

Agent 系统里最容易被低估的成本，也正好落在这层。模型换代很快，harness 却慢得多，因为它绑定的是动作链、信号链和失败链。只要这层没收紧，模型能力往前走，系统也只会更快把混乱放大。

纯读请求、一次性分析脚本、没有外部动作的轻量代理，模型能力仍然是主角。只要开始接私有数据、长期状态和真实动作，先变硬的就不再是模型参数，而是输入边界和信号边界。Agent 真正像系统的那一刻，往往就是这两层先站稳的时候。