04｜pi-agent-core：为什么 tool calling 不等于 Agent

这篇写什么

只讲一个关键点：为什么“模型会吐 tool call”不等于“系统是 agent”，以及 pi-agent-core 这一层到底补上了什么。

先说结论

pi-agent-core 的本质不是“再包一层模型调用”，而是：把一次模型调用变成一个可以持续推进任务的运行时闭环。

• pi-ai 解决：怎么把不同模型统一接起来
• pi-agent-core 解决：怎么让模型不只是回答，而是真正持续工作

为什么第一层还不够

如果系统只有模型抽象层，能力更接近：

• 把上下文发给模型
• 接收模型返回
• 把流式输出展示出来

即便模型支持 tool calling，这时也还没有“agent 感”。

因为“模型会吐出 tool call”不等于“系统能把任务做完”。

用户真正感知到的 agent 能力通常是：

• 它会自己去查信息
• 它会自己调用工具
• 它会根据结果继续下一步
• 它不是一轮问答，而是围绕任务持续推进

这些体验来自 runtime 闭环，而不是来自单次模型调用。

这一层到底解决什么问题

核心问题只有一个：

把模型、工具、上下文和外部反馈组织成一个持续运行的任务循环。

最短链路是：

用户提任务
-> 模型分析任务
-> 模型决定调用工具
-> 系统执行工具
-> 把工具结果回灌给模型
-> 模型继续分析和决策
-> 重复直到完成

只要这条链成立，系统才算 agent。

为什么叫 runtime

因为它更像一个持续运行的小系统（状态机），需要长期维护动态过程：

• 接收用户输入
• 发起模型调用
• 监听模型输出事件
• 识别工具调用
• 触发工具执行
• 接收工具结果
• 更新上下文状态
• 再次调用模型
• 判断是否结束

agent 的核心不是“会说”，而是“会闭环”

闭环意味着：

• 模型输出不是终点
• 工具结果也不是终点
• 每一轮输出都可能成为下一轮输入
• 系统一直运行，直到达到可停止状态

pi-ai 与 pi-agent-core 的边界

pi-ai 负责

• 统一模型调用
• 统一上下文表示
• 统一工具 schema 输入
• 统一流式事件输出
• 统一最终 assistant 消息
• 统一 usage / cost / stop reason

pi-agent-core 负责

• 决定什么时候调用模型
• 决定什么时候执行工具
• 决定工具结果如何进入后续上下文
• 决定什么时候继续下一轮
• 决定什么时候停止整个任务
• 暴露 agent 级事件流

小结

tool calling 是原料，tool loop 才是 agent。

pi-agent-core 的价值就在于：把模型的动作意图工程化成一个可持续推进任务的闭环运行时。