Steerability via constraints

Steerability via constraints

这篇 arXiv 论文主张：coding agent 的可控性不应主要依赖更复杂的 agent scaffold，而应更多利用工程组织已经成熟的约束基底：access control、network policy、严格 coding convention、工具化文档入口和可审计运行环境。论文在一个包含 11 个插入后门的 Python codebase 上报告：小 reviewer model 的 backdoor recall 从无约束无工具的 54.5% 提升到约束基底加约 200 行 docs CLI 后的 90.9%。

为什么对用户重要

这与用户的 Hermes 工作流高度相关：Hermes 经常执行文件写入、代码修改、wiki 入库和自动化 cron。若只靠 prompt 告诉 agent “要小心”，控制力有限；更可靠的是把边界变成 substrate：权限、目录、命令包装、lint、测试、只读/写入分离、日志和 policy。

它补强 Harness-Engineering 的安全侧：harness 的核心不只是“让 agent 更强”，而是让 agent 在更容易被审查、更难越界的环境里工作。

机制 / 一阶原理

论文摘要给出的机制是：

1. 约束缩小行为空间：限制 agent 可访问文件、网络、命令和编码自由度，使坏行为更容易暴露，也降低 reviewer 要检查的状态空间。
2. 工具让 reviewer 看见关键证据：约 200 行 docs CLI 这种小工具可以把代码库的相关事实变得可查询，提升小模型 reviewer 的 recall。
3. 约束与工具独立贡献：论文声称 substrate 和 tools 各自都带来提升，组合效果更强。
4. 语言越弱，约束越重要：Python 默认保证少，因此 substrate-level oversight 的收益更大；Rust 等语言有更多静态保证，但仍可受益于 policy 和工具。

一阶原理是：scalable oversight 不是让 reviewer “更聪明地读无限代码”，而是让系统结构本身减少可疑空间，并把关键证据以低成本暴露出来。

与已有 wiki 概念的关系

• 与 Harness-Engineering：将 containment harness 具体化为 substrate-level constraints，而不是只靠流程 prompt。
• 与 Agentic-Coding：提醒 coding agent 的完成定义应包含约束环境下的验证，而非自由执行后的自我声明。
• 与 AI-Code-Review：review 质量取决于 review substrate；更好的工具和边界可让较小 reviewer 也更有效。

对 Hermes / llm-wiki 的可执行启发

1. 为高风险工具调用建立 wrapper，而不是只在 prompt 中写“谨慎执行”。例如发布、删除、批量移动、跨 profile 修改都需要显式 guard。
2. 把 wiki 入库验证做成小 CLI / script：检查 raw 存在、frontmatter、wikilink、写入记录、index/log 是否同步。
3. 对 cron radar 设置只写入 wiki/ai/ 与 raw/articles/ 的默认边界；跨域或 schema 变更应只报告建议。
4. 对 coding-agent 任务优先使用“受约束小环境 + 明确 docs/search 工具”，而不是把整个仓库和无限历史塞给 agent。

失败模式 / 边界

• 摘要级摄入，尚未阅读全文实验细节；数值应视为中等置信。
• 约束过强会降低 agent 解决开放问题的能力，需要按任务风险动态调整。
• 小 reviewer recall 提升不等于完全安全；backdoor 类型、代码库规模和工具设计都会影响外推。

写入记录

• 2026-07-05 09:02 CST：新增 source 页面，提炼 constraints/substrate 对 coding-agent oversight、Hermes guard 和 llm-wiki 验证脚本的启发。