我用过六个 AI 智能体框架：Trae、OpenCode、OpenClaw、PiAgent、Codex、zCode。这篇文章不逐个罗列它们的功能，只复盘一件事：我为什么从「重度自研编排」一路退回「AI 作为高质量执行者」这个极简定位。
结论先放这里：这几个框架功能都已经挺完善，差距不大。真正决定效率的不是框架，是使用姿态。
框架选择：每次转向都是一次取舍，我都有理由
这几个框架我都认真用过，每一次转向都有具体的原因，不是喜新厌旧。
| 框架 | 用它解决了什么 | 为什么没留下 |
|---|---|---|
| Trae | 早期可用 | 闭源，不支持 hook，想做深度改造或扩展几乎无门 |
| OpenCode + OhMyOpenCode 插件 | 解决了 Trae 的封闭 | OhMyOpenCode 不稳定，且过度编排、过度规划严重 |
| OpenClaw | 那时少数支持微信、飞书等手机端访问 | 过度设计：Memory / Skills / Tools 一堆 MD，默认注入 29 个工具——我用过的提示词开销最高的框架 |
| PiAgent | 可靠、好用 | 没离开，至今仍是我自由选择时的首选 |
| Codex | 尝试 | 不满意，没觉得比其他框架有明显优势 |
| zCode | 在用 | 没太多抱怨；选它只因 GLM 套餐的 1.5 倍额度 |
回头看，有一条规律贯穿始终：可控性优于封闭的便利。
Trae 闭源，断掉的其实不是某个功能，而是「按自己的方式扩展」的可能。OpenClaw 那 29 个默认工具也不是能力，而是一种强加的上下文负担。所以我现在宁可要一个能让我自己决定注入什么的框架。
转向极简：我真正需要的只有四个原语
OpenClaw 之后，我很明确地转向了极简主义。
大多数场景下，我不需要复杂的插件机制，也不需要注意力机制和上下文注入。至于动态的提示词压缩，我也不需要。对我来说，牢牢抓住四个原语就够了：
- AGENTS.md：给智能体一份明确的工作说明
- 子智能体：把大任务切成可并行、可审查的小块
- Skill：把可复用的能力封装成可调用的模块
- 斜杠命令：让输入更快、更准
这四个原语，我在 PiAgent 上重度实践过。我自己写了三个本地插件包：worktree 编排、模型路由、搜索桥。另外还写了 /deep 这条对抗式编排流程。
我还给八个子智能体角色分别定制了模型。除此之外，落了十一个 Skill 和十个 /wt-* 斜杠命令。
这套东西确实能跑，也确实可靠。但它也让我看清一件事：编排本身的复杂度，本身就是一种开销。
我搭过一支「24 小时团队」，然后还是放弃了
那套编排走到最后，我用 Pi 配合 n8n 搭了一个全异步的自动开发平台。
平台里有四个角色：scout / worker / reviewer / planner。另外挂了六个定时器，常驻轮询 issue 队列，目标是 7×24 无人值守开发。
它确实跑得起来，但效率不高。原因也很直接：提示词开销很高，收益却有限。常驻的编排意味着持续往上下文里注入内容。而它自动产出的大量代码，最后还是要人去 review、去测试、去回滚。算下来，与其让这套系统自己转，不如我直接介入。
这条偏好贯穿全文
解决问题是唯一目标。不管是自己做，还是用 AI，怎么用 AI，最终都只指向这一件事。
AI 的定位：我把它当执行者，不当决策者
搭过那套团队之后，我对 AI 的要求又收了回来：它是一个高质量的执行者。分工很清楚：
- 我：给出清晰的架构设计和路线图；
- AI：把我的想法变成事实。
具体说，我不需要 AI 有很强的设计能力和创新。我也不会让 AI 完全自主地做长程开发。相反，我会花大量时间 review AI 写的代码和文档，并亲自测试。
这也是为什么我会说「各框架差距不大、功能都已完善」。当 AI 被定位成执行者，框架之间那点能力差异，就被我自己的介入抹平了。
在我看来，智能体这一轮发展已经趋于稳定。功能都够用，再继续加码，必然走向 AI 的全自主开发。
但我不认为全自主开发是个高效方向
我始终觉得，全自主开发算不上高效。这里有几个判断。
第一，收益是不是线性的。让 AI 连续工作 8 小时，真的需要它再工作更久吗？我倾向于认为，收益是边际递减的。
第二，它更容易失控。时长越长，越容易偏离初衷，也越容易陷进泥潭里。
第三，代码会腐烂。长时间无监督产出的东西，质量会一路往下滑。
而现实是，简单的提示词引导就能让 AI 高质量干活。我不需要什么复杂编排，只需要一段说得清楚的指令：
并行调用 10 个子智能体，每一轮开发完成后，每个子智能体的工作都派一个子智能体审核，总共进行 10 轮，按瀑布式推进，依据我提供的开发文档执行。
这段话已经是很简化的描述了。我只要这样讲，AI 就能长时间高质量地工作。所以需要做很多复杂编排吗？其实并不需要。
收尾：这套用法有它的局限
这套用法当然有它的局限。我承认自己是个重度介入的开发者。架构和路线图都得我自己定，review 和测试也都不外包出去。它不适合那种追求「按下启动键就走人」的人。如果你想要的恰好是后者，我这套经验大概帮不上什么忙。
但在我的约束下，每个选择都是能解释的。框架选可控的，编排选够用的，AI 当执行者用。智能体框架之间的差距，没有厂商宣传的那么大。真正拉开效率的，是使用姿态——而使用姿态，是我自己的事。