Agent 工程先收紧上下文和传感器

这几天看一组关于 Harness Engineering 的讨论，最直观的感受不是“Agent 又多了一层新能力”，而是工程讨论的重心已经换了。以前经常先问模型够不够强，现在先盯上下文放多少、规则文件放多长、传感器给什么信号。模型还在中间，但真正开始决定稳定性的，已经是外面那层 harness。

上下文窗口大了，注意力不一定更稳

退修里有人提到，把 agents.md 控到 200 行以内。这个数字不是装腔，也不是行数崇拜，更像一种预算提醒。上下文窗口变大，只代表能塞进更多内容，不代表模型会更稳定地抓住该抓的部分。模型经常只盯住上下文的一小块，剩下的内容就算都在窗口里，也未必都进了注意力。

这件事在工程上很烦。规则越多，越容易把“约束”写成“噪音”；说明越长，越容易把真正必须遵守的内容埋进角落。把文件压到很短，不是为了让文档看起来整洁，而是强迫约束变得可见。模型面对的不是一份百科，而是一份有限的操作契约。

传感器不是把日志再喂一遍

另一个明显变化，是讨论开始往 computational sensors 上移。这里的传感器，不是简单埋点，也不是把系统日志原封不动塞回模型，而是把运行时状态压成少量可用信号。它要做的是筛掉噪音，不是制造新的上下文负担。

这也是为什么“换成 Rust 而不是 Python”会被拿出来说。重点并不在语言站队，而在控制力。传感器一旦要靠运行时边界、资源限制、异常路径和确定性输出来保证质量，语言和执行环境就不再只是实现细节，而是传感器本身的一部分。信号如果不稳定，模型再强也只是在不稳定的输入上做猜测。

把原始数据直接送进模型，短期看像是信息更充分，长期看常常只是把现场变得更吵。真正有用的传感器，应该先把“发生了什么”压成少数几条清楚的状态，再决定哪些细节留给人，哪些细节留给工具。

harness 的职责是把世界切成可喂给模型的块

这类讨论一旦成熟，就会越来越像系统设计，而不是 prompt 技巧。harness 负责的是边界：哪些东西进入上下文，哪些东西留在上下文外，哪些状态可以被模型依赖，哪些状态必须通过工具再确认。它不是一个壳，而是一层过滤器和收口器。

这也是 Agent 系统里最容易被低估的成本。模型换代很快，harness 却会慢很多，因为它直接绑定动作链、信号链和失败链。上下文预算、传感器设计、权限边界、回退路径，最后都会落在这层上。只要这层没收紧，模型越强，系统越容易把不稳定扩散得更远。

现在看这类 fragments，最有价值的地方反而不是某个单点结论，而是它把工程重心说得很清楚：Agent 不再只是“会不会做事”，而是“外面的系统有没有把注意力和信号收拾好”。这一步没走稳，模型能力再往前，也只是更快地把混乱放大。