Skip to content

🐣 小a的成长烦恼

Agent 跑顺了——能调 LLM、会循环、有工具、能记、安全。但小a开始不满足:"如果我想支持多家厂商呢?想接 MCP 呢?想搞多 Agent 呢?"

老z:"好问题。但每一个『长大』都有代价。 今天我们讲清楚——什么时候该长,什么时候别长。"


31.1 长大的方向

我们的 Agent 现在 ~500 行,五脏俱全。它能往这些方向长:

方向长大后代价什么时候长
多厂商加 Provider 抽象复杂度、维护成本真需要换/比厂商时
MCP接 MCP 生态学习成本、依赖想用社区工具时
Skill加技能体系设计成本想让用户扩展时
多 Agent子代理/teams协调地狱真有并行需求时
TUI全屏界面大坑(第 19 章)产品就是 CLI 时
RPC编辑器集成协议设计想做 IDE 插件时

31.2 长大方向一:多厂商(Provider 抽象)

触发信号:你想从 Anthropic 换到 OpenAI,或同时用几家比效果。

🧙 怎么长?

学 pi-ai(第 17 章):定义 Provider 接口,把"配置"抽出来。

typescript
// 从直接调 Anthropic:
fetch("https://api.anthropic.com/...", {...})

// 长大成:
const provider = providers["anthropic"];
fetch(provider.baseUrl, { headers: provider.authHeaders(...), ... })

代价:要为每家厂商写适配器(消息格式、流式、auth 都不同)。一家 ~50 行,N 家 N×50 行。

什么时候长?只有真需要 ≥2 家时。 只用 1 家,直接调最简单(YAGNI)。


31.3 长大方向二:MCP

触发信号:你想用社区现成的 MCP server(第 10 章),而不是自己写工具。

🧙 怎么长?

加一个 MCP client,连接 MCP server,把它的工具注册进我们的 tools(第 30 章留的挂载点):

typescript
// 伪代码
const mcpServer = connectMcp("file-browser");
for (const tool of mcpServer.tools) {
  registerTool(tool);  // 复用第 30 章的接口
}

代价:要实现 MCP 协议客户端(协议本身不简单)。

什么时候长? 当 MCP 生态里有你需要的工具,且自己写不划算时。


31.4 长大方向三:多 Agent(子代理/teams)

触发信号:任务能拆成可并行的独立子任务(第 12 章的四个信号)。

🧙 怎么长?

让 Agent 能"派分身":

typescript
// 伪代码
const subResults = await Promise.all([
  runSubAgent("调研竞品 A"),
  runSubAgent("调研竞品 B"),
]);
// 主 Agent 汇总

代价:协调地狱(第 12 章)——谁说了算、消息怎么传、状态怎么同步、成本 N 倍。

什么时候长?99% 不需要。 单 Agent + 好工具够用(pi 就这么选的)。只有真有"可并行 + 长期分工"时才考虑。


31.5 决策框架:该不该长?

🧙 三个问题,全"是"才长:

  1. 真有这个需求吗?(不是"觉得酷",是"现在就卡在这")
  2. 长大的收益 > 代价吗?(算清维护成本)
  3. 没有更简单的替代吗?(比如多厂商,不如先用环境变量切)

任一答"否",就别长。 pi 的复杂度是多年真实需求堆出来的,你别一天就堆上。


31.6 pi 的选择:它长到了哪?

回顾 pi 长成了什么:

🧙 pi 的"长大"轨迹:

  • 长到了多厂商(近 40 家,Provider 抽象)
  • 长到了 TUI(产品就是 CLI)
  • 长到了会话持久化(SQLite/JSONL/fork)
  • 长到了评测(pi-evals)
  • 没长到多 Agent(单兵哲学)
  • 没长到 RAG(不需要)
  • 没长到 Graph(Loop 够了)

pi 的"长"和"不长",都是基于真实需求的选择。 它长成现在这样,不是"全都要",而是"该要的要,不该要的坚决不要"。


本章小结

🐣 小a的第三十一课

┌──────── 让它长大 ────────┐
│                          │
│  • 六个长大方向:         │
│    多厂商/MCP/skill/     │
│    多Agent/TUI/RPC       │
│                          │
│  • 每个都有代价          │
│    → 别为了酷而长        │
│                          │
│  • 决策三问(全是才长): │
│    真有需求?            │
│    收益>代价?           │
│    没更简单替代?        │
│                          │
│  • pi 的选择:            │
│    该长的长,不该的坚决不│
│    (单兵/不用RAG/Graph) │
└──────────────────────────┘

关键认知:Agent 能长大,不代表该长。每个"长大"都是用复杂度换功能。先跑通最简版,等真实需求出现再长——YAGNI 是终身原则。


课后实验

  1. 审视需求:列出你"想让 Agent 长"的方向,用决策三问过滤,看哪些是真需求、哪些是虚荣。
  2. 试加一个 Provider:如果你想支持 OpenAI,试着改 llm.ts 成 Provider 接口。感受复杂度。
  3. 体会 pi 的克制:对比 pi 的 9 个包,看它"没做"什么(多 Agent/RAG/Graph),理解"不做什么"也是设计。

收官:把前 7 步拼起来,跑一个完整的 Agent。 → 第 32 章 · 完整产物与回顾