现代 AI 智能体的能力不仅取决于基础模型，也依赖负责构造提示词、管理状态、调用工具和协调执行的 harness。随着模型、API、运行环境和需求变化，这层代码需要持续调整。论文认为，真正拖慢修改的往往不是写代码，而是先找全实现目标行为的代码位置。
从文件结构转向行为结构
生产级 harness 通常规模较大、耦合紧密，同一项行为可能分散在多个模块中。与此同时，修改请求描述的是“系统应该做什么”，代码仓库呈现的却是文件、类与函数。代码搜索、仓库索引和长上下文可以减少阅读成本，但仍需要开发者或智能体手工完成从行为到代码的映射。
Harness Handbook 试图补上这一层。它通过静态分析与 LLM 辅助整理，从现有代码库自动生成面向行为的表示，并把每项行为连接到对应源代码。相比单纯建立文件索引，这种表示更接近修改请求的表达方式，目标是让维护者先理解系统行为，再进入具体实现。
渐进披露，而不是一次塞入全部代码
论文还提出 Behavior-Guided Progressive Disclosure（BGPD）：先用高层行为引导智能体缩小范围，再逐步展示相关实现细节，并依据当前源码验证候选位置。这个验证环节很重要，因为 handbook 本身是派生表示，代码演进后可能出现偏差，不能被当作永远正确的文档。
在两个开源 harness 的多类修改请求上，借助手册进行规划提升了行为定位和编辑计划质量，同时减少了规划阶段使用的 token。摘要没有提供具体数值，因此目前只能确认方向性的改进，不能据此判断它在更大仓库或不同架构中的收益幅度。
我的判断
这项工作的价值在于把智能体代码维护中的隐性步骤正式化：修改前先建立“需求行为—实现位置”的可检查映射。它可能适合行为跨模块分布、工具链复杂、修改频繁的 harness，也能为代码智能体提供比全文检索更稳定的导航层。
边界同样明确：手册质量依赖静态分析、LLM 整理和源码校验，动态行为、运行时配置或外部服务造成的影响未必能被完整捕获。现有结果也仅来自两个开源 harness。它更像代码搜索与上下文管理的补充，而不是替代测试、运行时观测和人工审查的完整方案。