DCP：不是简单的截断
AI 编程会话最大的痛点是上下文窗口。聊着聊着 Agent 就开始"失忆"，或者为了腾出空间粗暴地截断前面的对话------把关键信息一起扔掉了。OpenCode 内置的压缩机制就是用截断来解决窗口溢出，但这对长会话来说不够精细。
DCP（动态上下文裁剪）提供了一种更智能的替代方案。它不等到窗口快满了才被动操作，而是在适当的时候主动将已完成的对话阶段压缩为高保真摘要。关键机制有三层：
第一层是阈值调优------专门针对 DeepSeek V4 的 128K 窗口：在 45K Token 时就温和提醒可以压缩了，到 85K 时强力推动。这样始终预留了足够的缓冲给即将到来的新内容，不会出现"聊到关键处突然压缩"的尴尬。
第二层是保护策略------子 Agent 的任务输出、技能加载结果、Todo 列表都被标记为不可裁剪。这意味着编排器派发出去的每个分析报告、每个实现方案都不会在压缩中丢失，被压缩的只有探索过程中的噪音和死胡同。
第三层是摘要缓冲。压缩后的摘要不占用上下文上限------编排器可以累积多次对话阶段的知识，而不必为每个新的思考腾出位置。实际可用的认知窗口远大于裸窗口。
代码审查的"有效逻辑体量"路由
传统的代码审查工具按文件行数计算审查量。一个两千行的 Lockfile 和一个两百行的安全模块，在行数计算下前者反而更"重要"------这显然是荒谬的。
借鉴 DeepReview 的设计，我在审查技能中引入了按文件类别加权计算的方式：生成文件和 Lockfile 权重为零，配置文件和 Fixture 打折计算，测试文件对折，只有业务逻辑源码全额计入。审查深度不是看改了多少行，而是看改了什么。
对于改动较小且不涉及安全敏感模块的场景，走简化审查路径------单轮聚焦，直接在对话中报告。对于大改动或触及认证、数据库迁移、并发逻辑、公开接口的场景，强制走完整审查------逐维度展开，写入文件而非塞满上下文。
另一个改进是熵扫描。在正式审查之前先做一轮模式检测：整个 diff 中有没有逐字重复超过六行的代码块？命名风格是否有漂移？有没有引入未使用的导入？这些问题在单文件审查时容易被忽略，但从整个变更集的视角看就是系统性信号。
审查-修复循环的收敛控制
审查完要修复，修复完要再审------这个循环如果没有收敛条件，Agent 可能在两个方案之间反复横跳，至无止境。
借鉴审查收敛的概念，我在循环中内置了四个终止条件：代码干净立刻停，同一问题连续出现两次说明陷入僵局也需要暂停，连续三轮没有发现新问题且老问题没有减少说明进入平台期，五轮作为硬性上限防止无限循环。
让 Agent 学会"交接工作"
长会话的另一个痛点是 Agent 交换。当编排器想把一个长会话交给新的执行 Agent 时，常见的做法是把整个对话历史粘贴进去------既浪费 Token，又让新 Agent 淹没在无关细节中。
Handoff 技能解决了这个问题。它不复制对话，而是生成一份指向关键产物的摘要：规划师的设计文档在哪个路径，Oracle 的分析报告在哪个路径，当前的任务清单状态是什么。新 Agent 按路径去读文件，只获取自己需要的信息。
让 Agent 学会系统化调试
大多数 Agent 遇到 Bug 时会直接猜测原因然后尝试修复------这是人类初级程序员的习惯，效率很低。Diagnose 技能把排查流程收敛为六个阶段，每一步都有明确的目标和产出：
复现是第一关------如果问题不能稳定复现，后续所有工作都是瞎猜。最小化还原是第二关------把问题场景拆到最简，排除干扰因素。然后提出三到五个假设，按可能性和验证成本排序，而不是想到哪个试哪个。用最轻量的手段验证假设（日志、断点、单测），只做最小化修复，跑回归测试保证没有引入新问题，最后清理所有临时调试代码。
这个方法论本身不新，但把它压缩到 Agent 能严格遵循的提示词里，能显著减少"试了十几种方法但不知道哪种生效了"的浪费。
实验功能的渐进启用
OpenCode 提供了一些实验性功能，通过环境变量控制开关。后台子代理允许一次派发多个独立任务并行执行------探索三个模块或审查前后端代码不必串行等待。批量工具调用让 Agent 一次返回多个操作，减少来回通信。这两项能力对并发场景的效率提升是直接的，且都不需要安装额外插件。