为什么 Pi 突然火了？Agent 竞争从功能清单走向 harness
Pi 突然火，真正的看点不是"它是不是又一个 Coding Agent"，而是 Agent 竞争的评判标准正在换轨：从比功能清单，变成比 harness。
- 功能清单时代：比谁的 sub-agent、plan mode、memory、MCP 更全
- Pi 的反常克制：核心只留 read / write / edit / bash，能力全部外置
- 卖点变了：不是"我帮你做好了一切"，而是"给你一块可改装的底盘"
- 三条路线：Pi 是可塑底座，OpenClaw 是常驻入口，HermesAgent 是学习循环
- 新的评判维度：能不能改造、工具怎么接、权限怎么管、上下文怎么压缩
Prompt 像说明书，harness 才是方向盘和刹车——这才是 Pi 这波火起来的底层原因。
Pi 卖的不是功能，是一块可改装的底盘
大多数人看 Pi，第一反应是"又来一个编程 Agent"，然后开始数它有没有 sub-agent、有没有 plan mode、有没有 memory。这条路走不通——按功能清单去理解 Pi，会完全错过它火起来的原因。
Pi 的思路反而很克制。它默认的核心很薄，只保留 read、write、edit、bash 这几样基础能力，把 Extensions、Skills、Packages 这些能力全部外置出来，交给用户自己去改造工作流。
这意味着 Pi 卖的不是"我已经帮你把一切都做好了"，而是"我给你一块可改装的底盘"。功能多不再是卖点，能被改造才是。
功能清单 vs harness：评判标准变了
Agent 的竞争，正在从"功能清单"走向"harness"。harness 这个词，直译是"挽具、套具"——套在马身上、让你能控制这匹马的那套装置。放到 Agent 上，它指的是模型之外那一整层控制结构：工具怎么接进来、权限边界在哪、上下文怎么组织和压缩、历史怎么留存、请求路由到哪个模型。
功能清单和 harness 是两种完全不同的评判维度：
| 维度 | 功能清单视角 | harness 视角 |
|---|---|---|
| 关心的问题 | 它有没有 X 功能 | 它能不能被改造成我要的样子 |
| 能力来源 | 官方内置、越多越好 | 用户外置、按需装配 |
| 护城河 | 功能数量 | 可扩展、可治理、可自定义 |
| 天花板 | 官方想到了什么 | 用户能拼出什么 |
功能清单是有限的——官方能想到的场景就那么多，堆到一定程度就会同质化。harness 是开放的——只要底座够薄、扩展点够清晰，用户能拼出官方从没预设过的工作流。Pi 赌的是后者。
三条路线：Pi、OpenClaw、HermesAgent
把 Pi 放进更大的坐标系里看，会更清楚它站在哪。当下三个有代表性的产品，其实各自代表一条不同的路线：
- Pi——可塑底座。重点是可扩展、可治理、可自定义，更像一套工程底座，你在上面自己搭。
- OpenClaw——常驻入口。重点是接进 Telegram、Slack、微信、QQ 这些真实沟通入口，更像一个随时在线的个人助理网关。
- HermesAgent——学习循环。重点是记忆、技能沉淀和自我改进，更像一个会随时间变强的长期协作者。
它们不是谁替代谁的关系，而是三个不同方向：一个往"可改装"走，一个往"离用户更近"走，一个往"越用越聪明"走。看清这三条线，就不会再拿功能清单去横向对比它们——它们本来就不在同一个评分表上。
做 Agent 产品，光问"它会不会回答"已经不够
如果只问"它会不会回答问题"，几乎所有 Agent 都及格。真正拉开差距的，是下面这几个 harness 层面的问题：
- 它能不能被改造？——扩展点是否开放，用 户能不能改工作流。
- 它怎么接工具？——MCP、插件、外部 API 的接入是不是干净。
- 权限怎么管？——哪些操作要审批，边界在哪，出事能不能兜住。
- 上下文怎么压缩？——长会话怎么裁剪、检索、保留关键信息。
- 历史怎么复盘？——跑过的东西能不能回看、审计、复现。
- 模型怎么路由？——不同任务能不能派给不同模型，成本和效果怎么平衡。
这六个问题没有一个是"功能"，全都是 harness 层面的问题。一个 Agent 能不能长期用下去，往往不取决于它多会答，而取决于这几件事有没有想清楚。
Prompt 像说明书，harness 才是方向盘和刹车
Prompt 决定这一次 Agent 怎么理解任务，像一份说明书；但真正决定它跑得稳不稳、能不能刹得住、出格了能不能拉回来的，是 harness——方向盘和刹车都在这一层。
说明书可以写得很漂亮，可没有方向盘和刹车，车照样开不了。Pi 这波火，本质是越来越多人开始意识到：Agent 产品的下半场，比的不是谁的说明书更长，而是谁的 harness 更扎实。