pi-mono 学习 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. 是否出现工具调用
  • 有工具调用:通常意味着任务还没完成,应执行工具并回灌后继续
  1. stop reason(结束原因)
  • 正常停止:通常可结束
  • 工具调用停止:通常应继续
  • 长度截断:可能需要补救或总结
  • 错误/中断:通常中止或交给上层策略处理
  1. 工具执行是否成功
  • 工具失败时:回灌错误给模型让其改策略,或按策略重试/终止
  1. 运行时护栏
  • 最大轮次、最大工具次数、最大连续错误数等

一个最小可用闭环(施工版)

最小闭环通常至少包含:

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

小结

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

Read more

传统 SaaS 转向 AI 时代,我目前的一点理解:先把数据能力变成 Agent 可调用的基础设施

最近我一直在思考一个问题:传统 SaaS 到底应该怎么转向 AI? 一开始很容易想到的方向是:给原来的系统加一个 AI 助手。 比如在页面右下角放一个聊天框,让用户可以问数据、生成报告、总结内容、解释指标。这个当然有价值,但我现在越来越觉得,这只是比较表层的一种转型。 真正的变化,可能不是“在 SaaS 里面加 AI”,而是 SaaS 本身的能力形态发生变化。 过去的 SaaS,核心是给人使用。 人登录系统,看页面、点按钮、筛选数据、导出报表、判断问题,然后再去做决策。数据库是给 Web 页面供数的,后端 API 是给前端页面服务的,整个产品的中心是“人如何操作软件”。 但 AI 时代,尤其是 Agent 逐渐发展之后,

By ladydd

对 Python 应用场景的一次重新思考:FastAPI、协程、线程、数据库与任务系统边界

最近在重新设计一个任务系统时,我顺便把自己对 Python,尤其是 CPython 应用场景的理解重新梳理了一遍。 这次讨论的背景是一个典型的异步任务服务: 上游提交任务 API 立即返回 task_id 后台 worker 慢慢执行 用户通过 task_id 查询任务状态 任务主要是 LLM 调用、图片下载、外部 HTTP 请求这类 I/O 型工作。 一开始关注的是队列、Redis、PostgreSQL、worker 并发控制这些问题。但聊到后面,其实更核心的问题变成了: Python 到底应该放在什么位置? 哪些并发适合 Python? 哪些并发不要硬塞给 Python? FastAPI、协程、线程、数据库之间应该怎么分工? 这篇文章就是这次思考的整理。 一、我不想抛弃 Python,

By ladydd

Go 和 Python 的并发模型对比:进程、线程、协程、并发和并行到底怎么理解?

最近我在写 worker 任务系统的时候,重新理解了一遍 Python 和 Go 的并发差异。 以前写 Python,多 worker 经常要考虑: 多进程怎么管理? 日志会不会串? 一个 worker 崩了怎么办? 怎么吃满多核心? 后来换成 Go,发现一个进程里开多个 goroutine worker 就很自然: go worker(1) go worker(2) go worker(3) go worker(4) 日志也好管,状态也好管,而且单进程还能利用多个 CPU 核心。 一开始很容易误会成: Python 不行,Go 行 但更准确的理解应该是: Python 和

By ladydd

Python 进程和 Go 进程的区别:为什么 Go 单进程多 worker 用起来更爽?

最近我在做 worker 任务系统的时候,突然意识到一个很关键的问题: 以前写 Python,多 worker 的时候经常要小心日志串、文件切割乱、时间不好管理。 但是换成 Go 以后,一个进程里开多个 goroutine worker,反而可以比较自然地写到同一个日志文件里。 一开始我以为这是“Python 和 Go 写日志能力不一样”,后来想明白了,核心不是日志本身,而是: Python 常见 worker 模型:多进程 Go 常见 worker 模型:单进程 + 多 goroutine 这背后其实是两个语言在并发模型上的巨大差异。 一、进程、线程、goroutine 先分清楚 先把几个概念捋一下。 进程:操作系统分配资源的单位 线程:CPU 调度执行的基本单位

By ladydd
陕公网安备61011302002223号 | 陕ICP备2025083092号