安全使用 RTK 的工程策略

4.1 默认压缩，但不要默认信任

最实用的策略不是全局禁用 RTK，而是把 RTK 变成分级观察系统。低风险命令默认压缩，高风险命令默认保存原文，关键生产操作前必须展开验证。这样既保留 token 成本收益，也避免在需要完整证据时被摘要牵着走。

建议把命令分成四层。

这个分层可以通过 RTK 的 exclude_commands、tee mode、Agent 系统提示和 wrapper script 组合实现。最关键的是 L2 与 L3 分界：观察可以压缩，破坏性动作不能只基于压缩摘要执行。

4.2 展开触发器

Agent 应被要求在以下信号出现时主动展开原始输出。

• 摘要只包含错误类型，没有 service、host、pod、region、version 或 timestamp。
• 建议动作会改变生产状态，例如 restart、scale、rollback、delete、apply、migrate。
• Agent 使用了“可能是”“通常”“建议先”等不确定措辞，但仍准备执行动作。
• 同一问题连续重试两次以上，或者修复后摘要没有变化。
• 摘要显示 truncation，例如只展示前 10 行、部分文件、部分日志窗口。
• 错误是跨系统的，例如网络、认证、数据库连接、消息队列、DNS、证书。
• 摘要中出现 dedup count，但没有时间跨度或实例分布。

这些触发器不需要复杂模型。可以写进 Agent instruction，也可以由外部 harness 在命令执行前检查。对于团队级落地，更推荐外部 harness，因为它不会依赖模型每次都记得规则。

4.3 推荐工作流

flowchart TD
    A[Agent 请求执行命令] --> B{命令风险分级}
    B -->|L0 L1| C[使用 RTK 压缩输出]
    B -->|L2| D[RTK 压缩并保存完整原文]
    B -->|L3| E[绕过 RTK 或强制 raw]
    C --> F{是否出现不确定信号}
    D --> F
    F -->|否| G[继续推理]
    F -->|是| H[读取 tee 原文或重新 raw 执行]
    H --> I[比较摘要与原文]
    I --> J{准备生产变更}
    J -->|否| G
    J -->|是| K[列出证据和风险]
    K --> L[人工确认或审批]

这个流程的重点是把“展开原文”做成自然路径，而不是异常路径。RTK 摘要应该帮助 Agent 快速找到怀疑点；一旦要做强结论或强动作，就回到原始证据。

4.4 Agent 提示约束

建议在全局 Agent 指令中加入类似约束。

RTK output is a compressed observation, not complete evidence.
Before production-impacting actions, inspect raw output or tee logs.
If an RTK summary lacks service, host, region, timestamp, or count distribution, ask for expansion.
Never infer absence of a warning or event only because it is absent from compressed output.

这段提示的作用不是让模型拒绝使用 RTK，而是校准它对证据完整性的认识。尤其是最后一句很重要：压缩输出中没有出现 warning，不等于原始输出没有 warning；压缩输出只显示 3 个错误，不等于只有一个服务受影响。

如果使用 Codex、Claude Code 或其他支持项目规则文件的 Agent，可以把这段提示放进团队模板。若组织已经使用 RTK 全局 hook，还应在 RTK.md 或等价规则中同步配置说明：哪些命令会被重写、如何读取 tee 文件、哪些场景必须 raw。

4.5 配置建议

RTK README 展示了基本配置路径和示例：

还建议在团队侧增加两个外部指标：summary/raw mismatch rate 和 expansion rate。前者衡量 RTK 摘要与原文在关键字段上不一致的比例；后者衡量 Agent 或人工需要展开原文的频率。如果某个命令族的 mismatch rate 高，应降低压缩等级或重写过滤规则。

4.6 与 RAG、RepoMix、PromptPacker 的关系

Medium 文章末尾建议将 RTK 与 GrepAI、RepoMix、context caching、PromptPacker 等组合使用。这个方向是对的，但需要明确分工。

RTK 适合处理 动态工具输出，例如刚刚运行的测试、日志、构建结果。RepoMix 或 PromptPacker 更适合处理 静态代码上下文，例如把仓库结构、关键文件、AST 摘要打包给模型。RAG 适合处理 可检索知识库，例如文档、历史 incident、runbook、设计文档。Context caching 适合处理 重复稳定上下文，例如项目规则和依赖说明。

不要让所有工具都做“摘要”。更好的结构是：检索工具负责找相关证据，RTK 负责压缩高噪声观察，缓存负责复用稳定上下文，Agent 负责在关键节点请求原文展开。

参考资料

• RTK README
• RTK Architecture Documentation
• RTK Telemetry Documentation
• Medium 原文