工具数量的悖论#

这是最直观的差异，也是最容易被误解的。

LangGraph 的工具列表可以轻松超过 50 个——文件操作、数据库、搜索引擎、API 客户端、向量存储、记忆管理、JSON Schema 验证……每个都经过精心设计，有完整的类型标注和错误处理。

CrewAI 少一些，但也在 10-30 个之间，按角色分类。

AutoGen 不太强调”工具”概念，但它内置的 Agent 类型协议和通信机制本质上也是一种预置能力。

Pi：4 个。

数字上的差距看起来大得荒谬。但这里有一个反直觉的事实：工具越多，Agent 的决策空间越大，出错概率越高。

想象一下，你让一个 Agent”帮我修这个 bug”。如果它面前有 50 个工具，它需要先判断该用哪一个。这个判断本身就会消耗 token、消耗时间、而且可能判断错。而如果只有 4 个工具，它的选择范围极小——读代码、改代码、跑测试。几乎不会选错工具。

这不是说少一定好。而是说：工具数量和能力边界是两回事。

Pi 用 4 个工具通过自举可以达到的能力边界，理论上和其他框架用 50 个工具达到的边界是一样的。区别在于到达的方式不同——一个是预先铺好的高速公路，一个是自己踩出来的小路。前者快但僵化，后者慢但灵活。

扩展方式的分水岭#

这是所有维度中最重要的一个。因为它决定了框架演化的方向。

传统框架的扩展 = 开发者写代码。

• 你想给 LangGraph 加一个新能力？写一个自定义 Node，注册到图里
• 想给 CrewAI 加新角色？定义一个新的 Agent 类，写好 role 和 goal，挂进 crew
• 想给 AutoGen 加新的对话协议？继承 BaseChatAgent，实现你的消息处理逻辑

这些都需要人类开发者动手。每加一个能力，都是人在写代码。

Pi 的扩展 = Agent 写代码。 Agent 发现自己缺能力 → 自己写脚本补上 → 后续复用。全程不需要人参与。

这两种模式的差异，不只是”谁写代码”这么简单。它意味着：

• 传统框架的能力上限 = 开发团队的交付速度
• Pi 的能力上限 = LLM 的编码能力 × 迭代次数

前者受限于人力。后者随着模型能力的提升自动增长。GPT-5 比 GPT-4 更会写代码？那 Pi 的自举能力就自动变强了。不需要等框架作者发新版。

这可能是未来三五年 Agent 框架领域最重要的分岔路。

System Prompt 的隐藏成本#

这个点很少有人提，但被严重低估了。

System Prompt 的长度直接影响两件事：token 消耗和注意力稀释。

每次 Agent 开始一个任务，完整的 system prompt 都会被送入 LLM。如果你的 system prompt 有 5000 字符（这在功能丰富的框架里很常见），那每一个任务的每一次思考循环都要消耗这些 token。一天跑 100 个任务呢？一年呢？

更隐蔽的问题是注意力稀释。LLM 的上下文窗口是有限的。当 system prompt 里塞满了 20 个工具的详细描述、参数说明、使用示例时，LLM 分配给”理解用户真实意图”的注意力资源就会减少。

Pi 的 system prompt 是所有编程 Agent 中最短的之一。 原因无他——工具只有 4 个，没什么好描述的。省下来的 token 和注意力，全部集中在任务本身。

调试体验：被严重低估的竞争力#

用过 Agent 框架的人都知道一个痛苦的事实：当 Agent 出问题时，你很难搞清楚它为什么这么做。

• LangGraph 有 LangSmith 可视化平台，能看到图的执行路径——这是目前最好的调试体验之一
• CrewAI 有任务日志，能看到每个角色做了什么
• AutoGen 能看到多轮对话记录

但这些本质上都是扁平的日志。你看到的是”Agent A 说了 X，Agent B 回了 Y”。你看不到的是：“在那一刻，Agent A 为什么选择说 X 而不是 Z？”

Pi 的树形 Session 直接回答了这个问题。 每个决策分支都被保留，你可以完整回溯推理链路。配合热重载，你甚至可以在观察到问题后立即修改 Agent 的行为，接着在下一个任务里验证修复效果。

这种”观察→诊断→修改→验证”的闭环速度，是目前其他框架难以企及的。