05｜pi-agent-core：闭环、回灌与“继续/停止”到底谁说了算

这篇写什么

聚焦 pi-agent-core 最关键的运行机制：tool loop（闭环）与工具结果回灌，以及 runtime 如何决定“继续下一轮还是结束”。

先说结论：tool loop 才是 agent

pi-agent-core 的核心不是“支持 tool calling”，而是把 tool calling 变成 tool loop：

模型提出工具调用
-> runtime 执行工具
-> 工具返回结果
-> 结果回灌上下文
-> 再次调用模型
-> 判断是否继续

只要这条链路成立，系统才真正像 agent；否则只是“会发工具意图的聊天模型”。

什么叫“回灌上下文”

回灌上下文就是：把工具执行得到的外部结果，作为正式历史消息写回到模型下一轮可见的上下文里。

为什么必须这么做？

• 模型并不直接生活在外部世界，只能看见上下文
• 工具执行发生在模型外部，如果结果不进入上下文，模型就无法基于结果继续决策

所以回灌不是字符串拼接技巧，而是闭环成立的中心机制。

“继续还是结束”谁来决定

关键点：不是模型单独决定，而是 runtime 决定。

模型会给出信号（例如产生 tool call、自然结束、长度截断、错误等），但“要不要继续下一轮”是 runtime 的裁决。

runtime 常见判断依据

1. 是否出现工具调用

• 有工具调用：通常意味着任务还没完成，应执行工具并回灌后继续

2. stop reason（结束原因）

• 正常停止：通常可结束
• 工具调用停止：通常应继续
• 长度截断：可能需要补救或总结
• 错误/中断：通常中止或交给上层策略处理

3. 工具执行是否成功

• 工具失败时：回灌错误给模型让其改策略，或按策略重试/终止

4. 运行时护栏

• 最大轮次、最大工具次数、最大连续错误数等

一个最小可用闭环（施工版）

最小闭环通常至少包含：

1. 接收任务输入
2. 组织上下文
3. 调用模型
4. 解析模型输出
5. 若有工具调用：执行工具
6. 将工具结果作为正式消息回灌
7. 再次调用模型
8. 根据策略判断停止并返回

小结

pi-agent-core 更像调度器/状态机控制器：它不“替模型思考”，但让模型提出的动作意图能够被执行并回流为下一轮输入，最终形成可收敛的任务闭环。