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

三台机器部署 ClickHouse 高可用集群实战记录

本文是一份可发布版部署记录。真实 IP、域名、账号、密码、下载链接、业务目录名、机器唯一标识等敏感信息已经替换为占位符。命令中的 <...> 需要按自己的环境替换。 目标与拓扑 这次目标是用三台数据节点部署一套 ClickHouse 高可用集群,拓扑采用: 1 shard x 3 replicas 含义是:集群只有一个逻辑分片,三台机器都保存同一份数据的完整副本。任意一台数据节点宕机时,只要 ClickHouse Keeper 仍然有多数派,剩余节点仍可继续提供读写服务。 规划节点如下: 主机名示例地址角色ch-01<ch-01-ip>ClickHouse Server + ClickHouse Keeperch-02<ch-02-ip>ClickHouse Server + ClickHouse Keeperch-03<ch-03-ip&

By ladydd

折腾记(二):接入火山引擎实时语音 API,家庭语音助手体验直接拉满

接上篇 上一篇用全开源组件(Whisper + Hermes + Edge-TTS)搭了个语音助手,能跑,但体验就是"能用"二字: * 中文识别只有 70 分,方言基本歇菜 * 英文唤醒词"Alexa"喊着别扭 * 说完到回复要等 4-8 秒 * 它说话的时候你插不了嘴 这些问题靠堆开源组件很难根治。于是我去试了火山引擎(字节跳动)的语音服务,结果直接换了条路。 这篇分两段:先讲怎么用火山引擎的 ASR/TTS 替换掉开源组件(小改),再讲怎么上端到端实时语音模型(大改)。 第一段:先把 ASR 和 TTS 换成火山引擎 为什么换 我用豆包输入法的时候发现它语音识别准得离谱。一查,豆包用的就是字节自家的火山引擎 Seed-ASR。开通后有免费额度(

By ladydd

折腾记(一):用全开源组件给家里搭一个语音助手,对接自己的 Hermes Agent

起因 事情是从一块 ESP32-S3 开发板开始的。 我手上有一块 Seeed Studio XIAO ESP32-S3 Sense,带摄像头和麦克风。最初的想法很美好:用这块板子做一个无线语音终端,对着它说话,连到我服务器上跑的 Hermes Agent(一个自托管的 AI agent),让它回答我。 但折腾到一半我突然意识到一件事:我的麦克风、音响、服务器全在家里,为什么要绕一圈用 ESP32?直接把麦克风和音响插到服务器上不就行了? ESP32 那条路(做无线拾音终端)当然也有价值,但那是"为了学嵌入式而学",不是解决问题的最短路径。于是这个项目就从"嵌入式项目"变成了"在服务器上拼一个语音助手"。这篇就记录后者。 教训零:先想清楚你要解决的是什么问题。很多时候最优解比你最初设想的简单得多。 目标

By ladydd

Kiro 的三种代理设置方法:本地、服务端、Remote

作为kiro的骨灰级用户,这篇是我自己折腾 Kiro / Kiro Remote / Ubuntu Server 代理问题后的复盘。 核心不是“怎么配一个代理”,而是先判断:到底是谁在访问外网? 谁访问外网,代理就要配给谁。 0. 先说结论 Kiro 相关代理大概分三类: 场景真正访问外网的进程在哪里代理应该配在哪里本地 KiroWindows / Mac 本机本机 Clash / Proxifier / 系统代理服务端 Kiro / CLIUbuntu Server 上的 shell、CLI、node、kiro 进程Ubuntu 的环境变量,比如 HTTP_PROXY / HTTPS_PROXYKiro Remote远程 Ubuntu 上的 ~/.kiro-server 和 extensionHost远程 Ubuntu 的 Kiro Server

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