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

把 Codex CLI 的登录态"搬"到一台新服务器

场景:你在一台老机器上早就登录好了 Codex CLI,现在开了台新服务器、装好了 codex,但它没登录。你不想在新机上重新走一遍 OAuth 网页授权(有时候服务器上根本打不开浏览器),只想把老机器上那份"已经登录好的身份"复制过去。 这篇讲的就是这个搬运动作的完整方法论——为什么能搬、怎么搬、有哪些坑。命令里所有隐私都用占位符,照着换成你自己的即可。 一、先理解一件事:Codex 的登录就是一个文件 这是整个操作的地基。Codex CLI(ChatGPT OAuth 登录模式下)的登录状态,不在什么系统钥匙串里,也不在环境变量里,就是家目录下一个单独的 JSON 文件: ~/.codex/auth.json 它长这样(字段名是真的,值我打码了): { "auth_mode": "

By ladydd

哨兵机制:让 Agent 一触即醒

0. 一句话点破本质 **让"等"发生在便宜的子进程里,让贵的 agent 只在有事时醒。**心跳解决"最迟多久必有人查岗",探针解决"事情一发生几乎立刻有人到场"——两个机制回答的是两个不同的问题,谁也替代不了谁。 1. 机制全貌:会自杀的轮询进程 + 宿主的"尸体通知" 我的实现只有两块积木: 积木一:一个有明确死法的后台循环 # 放行任务的同时,后台挂上(run_in_background) for i in $(seq 1 20); do 信号=$(ssh data "tmux capture-pane -t dna

By ladydd

Agent 心跳机制·设计与实现

0. 一句话点破本质 **心跳不是闹钟,是"带着完整世界快照的自我唤醒"。**闹钟只解决"什么时候醒";心跳真正要解决的是你点出的那个问题——醒来的那个瞬间,清楚自己是谁、任务到哪了、这一跳该干什么。我所有跑得好的心跳,提示词都写得像给一个失忆的陌生人看的;所有出过事的心跳,都是因为假设"我还记得"。 1. 第一性原理:为什么"醒来知道干啥"这么难 一个长期任务里的 agent 面临三重失忆: 1. 上下文会被压缩——多轮之后早期细节只剩摘要,心跳打进来时,那条心跳提示词可能是上下文里唯一高保真的任务描述 2. 世界在你睡着时变了——下属可能干完了、卡死了、跑偏了,你脑子里的"进度"从睡着那刻就开始过期 3. 任务本身会变—

By ladydd

我没手动映射 3000,公网为什么还能访问?一次 UPnP 误开孔复盘

写在前面:标题里的“自己打开”只是当时的主观感受。路由器没有失控,也不存在神秘穿透。真正发生的是:排障自动化从局域网主动调用了 UPnP AddPortMapping,路由器按协议新增了公网映射。 1. 原本的设计边界 家里的 Open WebUI 跑在一台 Ubuntu 主机的 Docker 中: 内网主机 192.168.x.x:3000 路由器上手动配置的入口是: 公网 TCP 13000 → 内网主机:3000 外部用户不直接访问家宽端口,而是先到云端 Caddy: 用户浏览器 → https://ai.example.com (云端 Caddy) → http://home.example.com:13000 (DDNS → 家宽公网

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