选 Agent 工具的第一步不是看哪个更火，而是分清三个东西：大模型（只输出文本）、Agent Harness（运行时底座：循环调度、工具注册、上下文管理、权限、状态持久化）、Agent 成品（在底座上封装好的产品）。同一个模型换不同 Harness，落地表现差距可以大到怀疑换了模型——胜负手往往在上下文工程和异常兜底，不在模型本身。
一张表看清主流玩家的定位差异
| 工具 | 开源 | 定位 | 模型绑定 | MCP | 设计取向 |
|---|---|---|---|---|---|
| Claude Code | 闭源 | 编码成品 | 优先 Claude，支持 BYOK | 原生 | 大而全、开箱即用 |
| Codex CLI | 闭源 | 编码成品 | 优先 GPT-Codex | 原生 | 云端沙箱、异步批量 |
| Pi-Agent | MIT | 编码运行时 | 完全无关 | 扩展包 | 内核约 1500 行 TS，四个基础工具 |
| OpenCode | MIT | 编码 Agent | 无关 | 原生 | Claude Code 开源平替 |
| DeepSeek-Harness | MIT | 通用运行时 | 完全无关 | 插件 | 一切皆插件、热插拔 |
| PrimeAgent | 开源 | 通用运行时 | 无关 | 原生 | 强规划、反思自省 |
| DeepAgents | 开源 | 高层工具集 | 无关 | 支持 | LangGraph 封装、快速出 Demo |
| CMP Agent | 开源 | 多 Agent 协同 | 无关 | 支持 | 角色分工、任务分发 |
表格里 MCP 一列"原生"和"插件实现"的差异值得展开：原生支持意味着工具发现、能力协商在进程内完成；插件实现通常要额外起一个 MCP Server 进程，走 stdio 或 HTTP 传输与主进程通信。stdio 传输是子进程管道，部署简单、延迟低，但生命周期跟主进程绑死；HTTP 传输可以远程共享一个工具服务，代价是要自己管认证和网络抖动。选型时"支不支持 MCP"只是第一层，"用什么传输、谁能共享"才是工程上真正要回答的问题。
五个维度做工程评估，别只看 Demo
Demo 能跑和能进生产之间隔着完整的评估链。五个维度按优先级排：
- 任务完成能力：端到端成功率、工具调用准确率、中途出错的反思回退能力、人工接管率。最后一项最容易被忽略——需要人频繁救场的 Agent，自动化收益基本被吃光。
- Harness 工程能力：上下文组装与压缩、会话持久化与中断恢复、全链路可观测、异常兜底。接口超时、模型输出坏 JSON、工具报错，每一项都要有兜底路径而不是直接崩。
- 扩展与开放：自定义工具/插件、底层 Loop 可改还是黑盒、模型可换、能否 SDK 嵌入。
- 安全治理：权限拦截审批、沙箱隔离、高危动作管控。企业落地这一项是一票否决制。
- 成本性能：系统提示词臃肿程度、每任务轮次、token 开销。Pi-Agent 那种极短提示词设计，单位任务成本可能比臃肿底座低一个量级。
增量：搭一套自己的评估基准，半天就能跑起来
与其背参数，不如拿真实任务打一轮。做法不复杂：
# 1. 准备 20 个有标准答案的任务（重构、修 bug、写测试各若干）
# 2. 逐个任务驱动 Agent 执行，记录全过程
agent --task tasks/07_fix_parser.yaml --log run07.jsonl
# 3. 从日志里统计三项硬指标
jq -s '[.[] | select(.type=="tool_call")] | length' run07.jsonl # 工具调用轮次
jq -s '[.[] | .usage.total_tokens] | add' run07.jsonl # token 总耗
git diff --stat # 改动面
判定标准建议：任务通过率 ≥80% 才算该场景可用；平均工具轮次超过任务步骤数两倍说明规划能力弱；单任务 token 超预算 30% 就要查上下文膨胀。再配一条回归集，每次升级 Agent 版本或换模型后重跑，能力退化当场暴露。
「一切皆插件」的价值与代价
DeepSeek-Harness 把主循环、模型适配器、工具、记忆、UI 全部拆成可热插拔插件，运行时动态装卸不重启。支持者看到的是自由度：企业场景千差万别，要 RAG 的、要多 Agent 的、要定制沙箱的，硬编码内核满足不了。质疑者也说到了实处：第三方插件权限很高，恶意插件可以读写文件、执行命令，生态越大供应链风险越大；插件多了之后依赖冲突、加载顺序、版本兼容都会变成日常排错项。
两个现实约束值得写进决策：其一，引入第三方插件前锁定版本并核对发布产物的哈希值，别用 latest 漂移引用；其二，给插件运行环境套网络出白名单和文件系统只读视图，把"插件自由"限制在业务需要的最小面内。
按场景给结论
- 日常写码、少折腾：Claude Code / OpenCode 这类成品，工程打磨成熟，直接用；
- 学原理、做 SDK 嵌入：Pi-Agent，1500 行内核读得懂、改得动；
- 企业私有化平台、多业务线共用底座：DeepSeek-Harness 这类微内核运行时，自由度换来的二次开发能力值得维护成本；
- 非编码的复杂规划任务：PrimeAgent；多 Agent 并行协同：CMP Agent；快速原型：DeepAgents。
没有银弹。成品与可插拔底座两条路线会长期并存——你的场景要"拿来干活"还是"拿来改造"，这一个问题基本就能定方向。
评论0