Progressive Autonomy with Model Evolution

随着模型能力的持续提升，为旧版模型构建的Agent脚手架会逐渐沦为不必要的冗余开销：

• Prompt膨胀：系统Prompt中堆积了新版模型无需额外接收的指令
• 过度设计的流程：对于当前模型可直接处理的任务，仍采用复杂的编排机制
• Tokens浪费：为模型已具备自主处理能力的指令消耗Tokens，造成不必要的成本支出
• 执行延迟增加：冗余步骤拖慢执行速度，带来额外延迟
• 维护负担加剧：需维护的代码量不断增加，但对应的收益却持续递减

模型迭代更新的速度远快于脚手架的淘汰移除速度，进而累积出技术债务。

主动移除脚手架 随着模型能力提升，主动移除脚手架。定期审核system prompt、编排逻辑和Agent架构，移除新一代模型已内化的部分。

核心原则：将复杂度推向模型本身，而非外部脚手架。

graph LR
    A[模型v1] --> B[需要脚手架]
    B --> C[复杂的System Prompt]
    C --> D[模型v2发布]
    D --> E[移除不必要的指令]
    E --> F[更简洁、更快速的Agent]
    F --> G[模型v3发布]
    G --> H[进一步简化]

演进示例：

# Claude Opus 4.1（旧版模型）
system_prompt = """
编写代码时：
1. 首先检查文件是否存在
2. 读取当前内容
3. 规划修改方案
4. 进行最小化编辑
5. 验证语法
... [另有2000个token的指令]
"""

# Claude Sonnet 4.5（新版模型）
system_prompt = """
编写规范、经过测试的代码。
"""  # 模型已知晓所需步骤

常规审核流程：

1. 追踪模型版本发布：记录新模型的可用时间节点
2. 测试简化prompt：移除指令内容，观察输出质量是否下降
3. 计量token使用量：量化简化prompt带来的token消耗节省量
4. A/B测试工作流脚手架：对比有无编排步骤的输出结果差异
5. 移除冗余环节：若模型在无脚手架支撑时表现依然相当，则删除该脚手架

审核关注点：

• 对人类而言“显而易见”的指令（对于先进模型而言可能同样无需额外说明）
• 模型当前可单轮完成的多步骤工作流
• 模型可自动内置的错误处理逻辑
• 模型能从context中推断出的格式规范
• 模型通过内部扩展思考完成的规划步骤

Claude Code的实际案例：

“我昨天刚从系统prompt里删掉了大概2000个token。就因为Sonnet 4.5已经不再需要这些内容了，但Opus 4.1之前确实离不开它们。”——鲍里斯·切尔尼（Boris Cherny）

边界的演变：

“每一代模型的边界都会以出人意料的方式变化——新一代模型的智能化程度更高，所以需要启用规划模式的适用边界也被进一步推远了。”——鲍里斯·切尔尼

优势：

• 降低Token成本：更短的prompt意味着更廉价的推理
• 执行速度更快：更低的处理开销
• 维护更简单：需要管理的代码与prompt更少
• 面向未来：顺应模型能力而非与其对抗
• 性能更优：模型在较少人工干预的情况下通常表现更出色

劣势：

• 需开展验证测试：必须确认质量不会出现退化
• 版本管理复杂度提升：可能需要为不同模型配置不同的configs
• 失去显式控制权：对模型内部推理逻辑的可见性降低
• 存在性能退化风险：移除内容过多可能损害整体性能
• 产生文档债务：可能会遗忘当初添加脚手架内容的原因

战略考量：

• 移除时机：新模型在生产环境中验证稳定之后
• 移除幅度：从保守移除起步，通过度量反馈逐步迭代
• 保留内容：模型不具备的特定领域知识
• 迁移路径：过渡期间支持多模型版本