不存在一个对所有代码仓库、Agent harness、预算和风险级别都最好的模型。真正有用的选择，是在兼容候选里找到能稳定通过你的验收标准、同时成本和速度都能接受的模型；任务含糊、链路长或出错代价高时，再切换到能力更强或推理投入更高的路线。
排行榜本身给不出这个答案。先定义任务，再排除不支持所需 harness、输入类型、工具或推理控制的模型，然后用有代表性的真实任务比较剩余候选。衡量的是完成任务、修复和人工审查的总投入，而不只是一次请求的单价。
最短规则：先筛选，再实测
按下面四道门依次判断：
- 兼容性： 具体的模型和供应商路线，能否配合你选择的 Agent harness、输入类型和必要控制？
- 任务适配： 它的能力和可用上下文，是否足以覆盖这项工作及其出错代价？
- 实际运营： 延迟、可用性、访问方式和预期总成本是否能接受？
- 证据： 它在相同真实任务上是否有足够稳定的通过率，可以成为默认选择？
顺序很重要。即使某个模型能力很强，只要 harness 无法调用，或任务需要图片而当前路线只收文本，它就不在候选范围内。单次 token 价格低，也不代表便宜；反复失败会带来更多调用和审查工作。
本文只解决模型选择。如果你还没分清执行层，可以先看 Agent harness 和模型为什么是两个选择。模型提供推理与生成能力，harness 则负责围绕模型组织上下文、工具、权限和执行过程。
从任务开始，而不是从模型目录开始
模型目录会变化，任务画像更耐用。打开模型选择器之前，先写下五件事：
- 最终要交付什么；
- 会涉及哪些文件、系统和输入类型；
- 需要多少跨仓库或领域推理；
- 测试或审查者能多快给出反馈；
- 一次看似合理的错误会造成什么后果。
这样可以把都被叫作“写代码”、实际上很不一样的工作分开。
这些只是任务路由的起始假设，不代表某个模型档位永远适合某一类任务。一个很小但陌生的缺陷，可能比大规模重复迁移更需要推理。因此，一份好的任务 Brief 应先写清目标、范围、验收和停止条件，再决定模型。
把任务翻译成可观察的能力要求
接下来，把任务画像变成可以观察的能力。仓库调查可能需要综合多份证据，并严格使用工具；从截图写代码需要图片输入；Schema 迁移需要在多份关联文件中遵守一致指令；代码 review 则需要可靠地指出问题，而不是生成一大段修改。
把能力拆成五个问题：
- 模型能否理解任务需要的每一种输入？
- 它能否处理这项任务所含证据的数量和类型？
- 它能否产出 harness 期望的代码、review 或结构化结果？
- 它提出的工具调用，是否足够准确地支撑这条工作流？
- 证据不足时，它能否遵守范围和停止条件？
供应商给出的能力定位适合制作候选名单。只有受控任务试跑，才能说明这些能力进入真实 Prompt、harness、工具和 runtime 后是否仍然成立。
先过兼容性硬门槛
“供应商提供这个模型”不等于“这个编程 Agent 可以使用它”。兼容性属于从 harness 到供应商再到模型的完整路线。
至少检查下面这些硬条件：
- 协议： harness 是否支持这条模型路线使用的供应商接口？
- 输入模态： 任务只需要文本，还是必须输入图片或其他内容？
- 输出与工具行为： 这条路线能否生成 harness 需要的结构化工具请求或其他输出？
- 推理控制： 如果流程依赖某种推理模式或强度控制，集成层是否真的能执行它？
- 产品可用性： 对你要使用的账号、地区、套餐和产品入口，这个组合现在是否开放？
Agent.Space 会在选定 harness 后应用兼容性 profile（能力配置），其中会检查协议、输入/输出模态和可执行的推理能力等合同。某一时刻真正能用的组合，以产品里的实时选择器为准，不能只凭模型供应商目录推断。
供应商文档仍适合核对模型这一层。OpenAI 当前的模型目录分别列出上下文、价格、模态和工具支持；Anthropic 同时提供模型概览，以及综合能力、速度、成本与实测的模型选择指南；xAI 也在当前的模型文档里维护各型号信息。把这些页面当作会变化的规格表，而不是一次记住就永久有效的数字。
把上下文当作预算，不要当作质量分
更大的上下文窗口回答的是容量问题：一次请求或一个 Session 的合同里能放多少输入和输出。它并不能证明放进去的每个 token 都相关、都能被正确加权，或都能被有效利用。
先估算任务真正需要同时参与推理的“工作集”：
- 指令和验收标准；
- 相关代码、Schema、日志或图片；
- 运行过程中累积的工具结果；
- 模型输出和推理表示所需的空间；
- 修正或最终验证回合的余量。
然后看 harness 怎样组织这些材料。好的仓库索引、搜索工具或检索策略，可能让较小但准确的工作集胜过一大包未筛选内容。反过来，即使模型标称上下文足够，只要 harness 漏了关键文件，或在压缩时丢掉早期限制，任务仍会失败。
长 Session 还要考虑上下文管理：harness 会摘要、丢弃还是重新加载早期证据？把这个行为记录下来。如果任务经常超出路线能可靠使用的上下文，答案可能是拆分任务、改善检索，或制作明确的交接材料，而不是自动购买标称窗口最大的模型。
比较“每个合格结果的成本”
每 token 单价只是成本输入，不是最终结果。对编程工作流，更有用的指标是：
不需要精确到财务报表，也能得到有用结论。记录几项可观察数据即可：
- 整个任务的模型和供应商用量，包括重试；
- 从开始到通过验收的总时长；
- 人工修正或追加提示的次数；
- 审查者发现和修复问题所花的时间；
- 没有形成可用产物的失败运行。
延迟也有两种含义。互动结对时，首个回复速度很重要；委派任务时，从开始到得到已验证结果的时间更重要。第一次回答很快，如果随后产生多轮返工，整体仍可能更慢。
即使模型名称相似，访问和计费路径也会改变经济性。Agent.Space 区分 Share 与 Flex，模型供应商也会独立调整价格、套餐和额度。成本会影响决策时，请检查当前产品和供应商页面，不要让旧对比表长期决定任务路由。
做一次受控模型试跑
有效评估的做法，是尽量只改变模型，其他工作条件保持稳定。从近期真实工作中挑三到五个任务，至少包括一个简单任务、一个常规任务和一个容易失败的任务。
每次运行都记录：
每换一个候选，都把代码恢复到同一状态。让各 harness 拥有完成任务所必需的同类工具，但不要假装不同供应商的控制项含义完全一样。遇到差异就记录，而不是强行做出虚假的一致。
先评价产物，再评价对话。Diff 是否留在范围内？测试是否通过？是否标出未经证实的假设？另一个人能否复现结果？流畅的解释有价值，但不能替代验收证据。
如果想看限定在一个当前模型家族里的决策示例，可以参考 Sol、Terra 与 Luna 对比。这些型号标签以后会变，但受控试跑的方法不应随之过期。
如果要评估当前旗舰新模型，可以先看 GPT-6 Astra 的 Coding Agent 指南，了解发布、rollout 与能力地图；再用 Astra benchmark 审计判断哪些公开数字可以比较。如果真正的问题是困难的 Sol 工作是否值得切到更高价路线，可直接看 Astra 与 GPT-5.6 Sol 决策指南。
把结果变成任务路由规则
不要选出一个永久冠军。把证据整理成一条很小的任务路由规则，告诉团队默认从哪里开始、什么时候升级。
一种实用做法是分三条路线：
- 快速路线： 有界、可逆、能做确定性检查的任务，从已经通过这类试跑的低成本路线开始。
- 深度路线： 含糊、跨仓库或链路长的任务，从在相似推理任务上更稳定的模型开始。
- 升级路线： 高后果任务无论使用多强的模型，都要增加更严格的权限、独立验证和人工审查。
把升级条件明确写出来，例如连续两次修复失败、出现范围外改动、缺少证据、工具调用报错，或任务进入受保护区域。这样既不会让便宜路线无限重试，也不会让强模型获得无限权限。
当供应商改变模型快照、harness 调整上下文或工具循环、价格变化足以影响路由，或者团队的任务结构改变时，重跑一组小基准。路由规则是一项需要维护的工作决策，不是模型的永久身份。
最后以 Agent.Space 实时选择器为准
在 Agent.Space 中，先选择符合执行方式的 Agent harness，再通过当前模型选择器查看这个 harness 与访问路径下的兼容模型。现在能否启动，由实时选择器决定，而不是本文或某条供应商公告。
对剩余候选按下面顺序操作：
- 按任务和出错代价选择对应路线；
- 使用有边界、带明确验收的 Prompt；
- 检查保存的产物和验证证据；
- 记录这条路线应继续作为默认、只用于某类任务，还是应移出候选。
这套方法不假设 Agent.Space 已经统一测试所有可见模型；“能看到”也不是质量背书。它只是让你在目录不断变化时，仍能重复生成属于自己的证据。
准备开始时，可以先查看当前的 Agent Hub，选择 harness，再用一个可验证的小任务测试兼容模型。