AIGC标识 给 AI 编程代理做"减法"：Token 经济学视角下的配置工程实践

过去几个月，我持续打磨一套 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（探索、审查、诊断类）的权限模型从"禁止编辑"升级为默认全拒 + 显式白名单：

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 提示词逐轮净减。但真正的收获不是数字，而是三个原则：

  1. 每个 Token 都是常驻成本——写 prompt 时想清楚"这句话值得每轮对话都付一次费吗"；
  2. 减法需要纪律——逐句测试、职责分离、白名单，都比"少写一点"更有效；
  3. 校验机制比规则本身更值钱——双轴交叉、校准基线、降级链，让系统在不确定时依然收敛。

如果你也在折腾 AI 编程代理的配置，希望这些实践能给你一些参考。

项目地址：https://github.com/znlgis/my-opencode-deepseek-config

posted @ 2026-08-13 12:55  我才是银古  阅读(29)  评论(3)    收藏  举报