过去几个月，我持续打磨一套 OpenCode + DeepSeek 的编程代理配置。回头看这一系列迭代，最大的体会是：做 AI 代理的配置工程，减法比加法难得多，也值钱得多。每往 prompt 里加一句话，都是此后每一轮对话都要支付的 Token 成本；而删掉一行废话，收益在整个会话周期里持续兑现。这篇分享围绕"上下文经济"展开，记录几个我认为最有复用价值的做法。
一、双层压缩：主动压缩与兜底各司其职
DeepSeek V4 的上下文窗口是 128K。窗口大不等于可以浪费------常驻 prompt 越长，缓存命中率越低，单次成本越高。我采用了双层压缩架构，核心原则是主动压缩优先于被动溢出：
- 第一层：DCP 剪枝 （对话上下文自动修剪插件）。触发阈值从绝对值改成了百分比 ------压缩上限从固定的 75K 改为
"60%"、温和提醒从 35K 改为"30%"。这样无论将来换什么模型、窗口多大，策略都能自适应，不需要重新调参。 - 第二层：原生自动压缩 作为近溢出兜底，并且把
prune: true打开，让它负责裁掉陈旧的工具输出。
关键是两层职责分离，互补而不重叠：DCP 只做范围压缩（连续对话压缩为高保真摘要）和去重（相同工具+参数的调用只保留最新输出），裁陈旧输出的活交给原生层。如果两层做同一件事，浪费的是双份计算和双份上下文。
几个容易踩的细节：
- 摘要本身不计入压缩阈值（
summaryBuffer: true），否则会出现"越压缩越触发压缩"的死循环； - 保护最近 4 轮对话不被裁剪（
turnProtection: 4），保住了短期工作记忆； - 允许压缩用户消息（
protectUserMessages: false）------这个默认值反直觉。如果设为 true，用户贴进来的 20K 行日志将永远无法被压缩，128K 窗口很快被一次粘贴打爆； - 配置文件（opencode.json、AGENTS.md、.env 等）加入保护列表，防止剪枝把"规则本身"给裁了。
二、逐句审查：No-Op 修剪
压缩阈值解决的是"会话变长怎么办"，但更根本的问题是：一开始就别塞多余内容。
我们的方法是逐句执行一个测试：
如果删掉这句话，Agent 的行为会改变吗？ 不变，就立刻删。
听起来像废话，实际执行起来杀伤力惊人。典型的可删模式：
- "Be thorough and careful" / "Make sure to..."------Agent 不需要被鼓励；
- "This is crucial because..."------废话前缀；
- 重复的步骤说明------别处已经描述过；
- 过度解释性段落------代码示例本身已经说明了用途。
配套的还有一条反直觉的纪律：正面表述优先。说"该做什么"，而不是"别做什么"。写"编辑前先读文件"，而不是"别忘了读文件"------否定式表述反而会让被禁止的行为对模型变得更"可及"。
通过逐轮修剪，AGENTS.md 从 290 行压到 180 行，技能文件总量削减约四分之一，常驻上下文（每次会话都要重复注入的内容）降低了大约 22%。
三、技能即成本：一技能一使命
Agent 的技能库不是收藏夹------每个技能都是常驻成本，技能列表本身要注入每次会话。所以我们确立了一条判据：功能重叠的删、纯包装器的删、可以内嵌成格式规则的删。
几个具体案例：
- 一个"深度工作"技能与既有工作流技能高度重叠，删除；
- 一个 290 行的"规范提交信息"技能，本质是格式规则，内嵌成一条命令规范即可；
- 一个只是包装了系统调试技能的"诊断"技能（它自己开头就写着"先加载系统调试技能"），删除；
- 一个 122 行的 GitHub 技能整体并入另一个 GitHub CLI 技能，净减 122 行。
技能数量经历了"增删并"的拉锯，最终稳定下来靠的是同一个标准：这个技能解决了一个别的技能解决不了的问题吗？
四、双轴代码审查与"校准"机制
代码审查是我投入最多的一块。核心改进是双轴并行审查：
- 规范轴：风格、命名、结构、注释、导入、错误处理------对照项目自身的编码规范；
- 规约轴：正确性、边界、安全、性能------对照任务需求本身。
两个轴并行跑完再合并去重。同一个问题被两个轴独立发现，标注为最高置信度------这比单轴审查多了一层交叉验证。
对抗"审查噪音"的机制同样重要：
- 有效大小分级：生成文件权重 0、配置文件 0.25、测试 0.5、业务逻辑 1。小改动默认走精简审查流程，省一个数量级的 Token；
- 严重度校准：按项目威胁模型降级（内部工具和公开库不该用同一把尺子）；
- Validator 校验：每条 finding 都要过四查------能构造反证吗？换个审稿人会不会通过？是缺陷还是个人偏好？引用证据在影响范围内吗？
- 共享校准基线：把"缺失鉴权的 localhost 内部工具降为 low"这类裁决沉淀进一个 git 跟踪的 YAML 文件。审查 Agent 命中这些 pattern 时必须按条目降级并引用，避免同一个低优先级问题每轮都被报成 high。
另外补了一个 28 行的"追问"技能：需求含糊时一次只问一个问题，优先给多选，意图一清晰立刻停------不为显得周全而继续问。
五、双层模型路由：半价的先上
这套配置用两个模型做分层路由，核心逻辑一句话：Flash 约半价，Pro 推理更强。
- 所有定义明确的工作------搜索、查文档、单文件小改动------交给便宜模型；
- 规划、分析、审查、复杂实现------才动用贵模型；
- 便宜模型是默认，贵模型是升级路径，不是默认选项。
配套的纪律：
- 意图门控：先识别真实意图再路由。"look into X" 不等于 "fix X"，前者只查不改；
- 先规划后动手：涉及两个以上文件或架构决策的任务，先出计划再实现；
- 写作用域隔离：两个执行 Agent 绝不重叠写同一个文件，静默的写入冲突会损坏产出；
- 降级链：每条路径都有预设的失败兜底------便宜模型搞不定就升级，执行失败就重新规划；
- 保护缓存命中：DeepSeek 的前缀缓存只有在早期消息字节级稳定时才生效------静态前缀保持不动，易变内容追加到 payload 尾部，绝不重排早期消息。这条纪律直接决定单次调用的成本。
六、只读 Agent 的白名单权限
只读 Agent（探索、审查、诊断类）的权限模型从"禁止编辑"升级为默认全拒 + 显式白名单：
yaml
permission:
edit: deny
task: deny
bash:
"*": deny
"git status*": allow
"git diff*": allow
"git log*": allow
"git blame*": allow
"rg *": allow只读角色连 bash 都只能跑白名单里的只读命令。同时清理了无效的权限键（比如一个并不存在于 schema 里的"禁止写入"键，编辑权限 deny 已覆盖写能力）和冗余规则（带空格和不带空格的 rm -rf 重复条目）。
安全敏感信息同样双向把关：.env 系列文件对读取权限全部 deny；而剪枝插件里又把 .env 加入保护列表，防止环境变量内容被误裁进摘要再泄露。
顺带一提，GitHub CLI 某版本修复了 4 个转义序列注入漏洞（终端输出可注入 ANSI 控制序列，甚至复制剪贴板）。技能里固化了规避规则：取外部仓库数据一律用 --json（JSON 不受转义注入影响），下载 release 强制落盘、禁止直接 pipe 到终端渲染器。
结语
回看这轮迭代的数字：命令从 29 个砍到 18 个（-38%），常驻上下文下降约 22%，技能、Agent 提示词逐轮净减。但真正的收获不是数字，而是三个原则：
- 每个 Token 都是常驻成本------写 prompt 时想清楚"这句话值得每轮对话都付一次费吗"；
- 减法需要纪律------逐句测试、职责分离、白名单，都比"少写一点"更有效；
- 校验机制比规则本身更值钱------双轴交叉、校准基线、降级链，让系统在不确定时依然收敛。
如果你也在折腾 AI 编程代理的配置，希望这些实践能给你一些参考。