模型相同效果不同？聊聊智能编程执行框架

一、一个常被误判的现象：问题出在模型，还是出在框架？

不少开发者都有过类似体验：看评测、刷榜单时对某个模型寄予厚望，正式订阅后却发现，它在 A 智能编程工具里表现平平；换个工具调用同一个模型，代码质量、任务完成度、返工率却明显改善。于是很容易得出“这个模型不行”的结论。

更接近真相的解释是：大模型只是引擎，执行框架（harness）才是整车。同一台发动机装在调校水平不同的底盘上，圈速可以差出一大截。智能编程场景尤其如此——智能体任务链条长、工具调用密集、上下文复杂，框架层面的每一个设计决策，都会被模型“如实”地放大成效率，或者放大成错误。

二、执行框架的五个核心组件

1. 系统提示词与任务编排

系统提示词决定了模型对自身角色、工作流程与输出规范的理解。成熟框架的系统提示词通常会明确约定：先探索仓库结构再动手、小步修改、每步验证、何时停下来向用户确认等。弱框架的常见问题是提示词过于简陋，模型拿到模糊目标后直接“开写”，缺少“先定位、再规划、再实现、再验证”的流程引导，结果往往是大改大错、小改小错。

2. 工具链与工具描述质量

模型并不能直接“看到”你的工程，它只能通过工具间接观察和修改世界。工具集的完备性（读文件、精确编辑、代码搜索、执行命令、查看测试输出）与工具描述的准确性，直接决定模型能否形成稳定的行为模式。举例来说：如果编辑工具只支持整文件覆盖，模型在长文件上就极易出错；若提供精确的按块编辑和清晰的失败反馈，成功率会显著提升。工具描述含糊时，模型会频繁“猜参数”，一个简单任务被拆成十几次无效调用。

3. 项目级上下文文件

这相当于“给新同事的入职说明”：构建命令、测试命令、目录约定、禁止触碰的区域、团队编码规范。框架若支持让仓库维护者把这些规则写成文件并自动注入每次会话，模型犯“常识性错误”的概率会大幅下降；反之，团队规则只能靠用户在对话里反复纠正，既低效又不稳定。

4. 子智能体与任务分解

面对跨模块重构、大范围缺陷排查这类长任务，成熟框架会把“规划、检索、实现、审查”分配给相互隔离的子智能体，避免主上下文被无关细节塞满。上下文窗口是稀缺资源，框架的任务编排能力本质上是在做“上下文工程”：什么信息该常驻主上下文、什么信息该随用随取、什么信息该及时裁剪。

5. 权限管理与安全边界

哪些命令允许自动执行、哪些需要逐次确认、哪些一律禁止。好的权限设计能在“减少打断”与“守住底线”之间取得平衡：粒度太粗，要么不安全，要么确认疲劳；粒度太细，智能体步履维艰，人反而成了流水线上的按钮工。

三、为什么成熟框架对强模型的增益更明显

一个朴素却准确的判断是：模型越强，框架的杠杆作用越明显。弱模型配好框架，天花板仍然是模型能力；强模型配差框架，能力却被大量浪费在返工和无效调用上。具体机制有四点：

• 反馈闭环：框架能自动运行构建、测试、静态检查，并把错误信息回灌给模型，模型才有自我纠错的机会。没有闭环，再强的模型也只能“盲写”。
• 上下文管理：自动裁剪、摘要、按需检索，避免长任务后期“失忆”——改着改着忘了最初的需求约束。
• 失败恢复：命令失败后的重试与降级策略、对报错信息的结构化解析，决定了一次失败是“三次调用内解决”还是“彻底卡死”。
• 确认节奏：何时自主推进、何时停下确认，直接决定人机协作的心流体验。

四、原生框架的优势与代价

自研框架并非没有价值，其优势通常体现在：

1. 成本控制：框架与模型协同设计，可以在提示词长度、工具调用次数、上下文重复注入等环节做压缩，同样的任务消耗更少的算力与费用；
2. 原生适配：模型的新特性（更长的有效上下文、新的工具调用协议等）可以第一时间在自家框架中启用，不必等待第三方跟进；
3. 迭代速度：模型与框架联合调优，问题定位链条短，出问题能快速闭环。

代价则在于：执行框架的打磨是典型的“脏活累活”，依赖大量真实场景的试错积累，短期很难追平打磨多年的成熟框架。因此“自家模型+自家框架”未必立刻优于“强模型+成熟框架”，反之亦然——关键看任务类型、成本约束与团队现状。

五、如何做一次公平的对比评估

与其争论“谁更好”，不如用控制变量法自己跑一遍：

1. 固定任务集：挑选 5–10 个有代表性的任务（新功能开发、缺陷修复、小规模重构、补测试、读懂陌生模块），难度覆盖日常工作；
2. 一次只改一个变量：固定模型、切换框架，或固定框架、切换模型；
3. 量化记录：一次通过率、人工干预次数、总 token 消耗、墙钟时间、返工轮数；
4. 归因失败模式：是理解错了需求（提示词/规则文件问题）、工具用错了（工具链问题），还是上下文丢了（上下文管理问题）——不同的失败模式指向不同的改进方向。

六、三个可以立刻上手的优化实践

1. 写好项目规则文件

# AGENT.md —— 项目协作规则示例
## 构建
- 修改代码后执行 ./build.sh，失败必须先修复再继续
## 测试
- 提交前运行 ./test.sh，确保全部通过
- 新增功能必须附带对应单元测试
## 风格
- 遵循仓库既有的静态检查配置，不引入新的风格约定
## 边界
- 不要修改 generated/ 目录下的自动生成代码
- 涉及数据库结构变更时，先输出迁移方案并等待确认

2. 配置细粒度权限

{
  "permissions": {
    "allow": ["read:src/**", "write:src/**", "run:./build.sh", "run:./test.sh"],
    "ask":   ["write:infra/**", "run:deploy*"],
    "deny":  ["write:.env", "run:rm -rf *"]
  }
}

3. 用子智能体隔离长任务

planner  = Agent(role="规划", tools=["read", "search"])
coder    = Agent(role="实现", tools=["read", "edit", "run_test"])
reviewer = Agent(role="审查", tools=["read", "run_lint"])
plan = planner.run("为订单模块补充退款逻辑，输出分步计划")
for step in plan.steps:
    change = coder.run(step)
    review = reviewer.run(f"审查改动：{change.diff}")
    if not review.passed:
        coder.run(f"按审查意见修复：{review.comments}")

七、结语：把框架成熟度当作一级选型指标

模型与执行框架是乘法关系，而非替代关系。选型时，除了看模型榜单，更应把执行框架的成熟度——工具链完备性、上下文工程能力、权限体系、子智能体编排——放在与模型能力同等重要的位置。对企业团队而言，还应把模型接入、审计与权限管控纳入统一基础设施：例如借助百度智能云等平台提供的通用能力类目（容器平台、日志服务、监控告警等）来承载自建智能体的运行与观测，让“模型+框架+平台”三者协同，把模型能力真正转化为可持续的工程效率。