返回课程总览 · 上一章 · 下一章

IndyDevDan · 51:36 · 发布 2026-02-23 · 22.8万次观看(截至抓取) · 观看原视频 🔥 观众最高回放 29:56 — 本片高回放时刻见对应章节

主旨

在 v2 minimal footer(model + context)之上,叠加一个”等待工具”的状态信号——当你跑 prompt 后等到模型该调用 bash / read 时,footer 多一句 “waiting for tools” 让你知道 agent 卡在哪——演示 footer hook 还可以被更细粒度的 lifecycle 事件钩入

核心论点

  1. Pi 把工具调用的生命周期可见化——不只显示”我在工作”,还显示”我在等工具”,这两种状态的语义不同。(→ 详解1)
  2. “Tool waiting” 是 agent 实际上吃 token 的关键节点——卡在 tool call 选择 / 参数构造的时间,模型在做决策,埋没在 context 里却显著影响最终输出质量。(→ 详解2)
  3. footer 是一个可任意加信号的”小看板”,而不是一条固定字符串——这是 Pi “全层可定制”的具体落地。(→ 详解3)
  4. v5 是 v6 widget 化的过渡——把一个信号塞进 footer 是一次尝试,后面 v6 直接把状态搬到独立 widget,信号变可视化面板。(→ 详解4)

知识点详解

1. 状态行捕捉 lifecycle event 13:44

You can see something cool here. Waiting for tools. Okay, interesting. Why is it waiting for tools? (13:44)

作者跑 prime,agent 没有立刻输出,而是停在 “waiting for tools” 状态——意味着模型正在构造下一次工具调用的参数。footer hook 监听 lifecycle 事件:从 onPrompt → onToolCall → onToolResult → onModelOutput,你可以挂任何事件让 footer 显示相关信号,这是把 Harness 的可观测性主张(看不见的 agent 改不了) 落到具体工程。

2. Tool waiting = 决策点 13:44

模型在 tool call 时做的事不是”打字”,而是选工具 + 构造参数。这一动作质量直接决定输出质量,与 AI 编码光谱 中 agentic engineer vs vibe coder 的分界一致:

  • 选错工具 → 走错路径 → 浪费 token + 输出错误
  • 参数构造错 → 工具失败 → 模型得自己诊断
  • 漏选工具 → 任务根本完不成

agentic engineering 的核心改进之一就是让这些选择可见,然后判断是否要给规则/hook。Pi 把这一可见性放进了 footer。

作者指出:You can really customize it to make it your own. (14:38) - footer 不只是装饰,而是可视化面板,在不喧宾夺主的前提下让你随时窥 agent 状态。这与 v1 极端心流的”我什么都不想看”形成对照——v5 是”我要的我就看,我不要的我自己配”。

4. 向 v6 widget 演化 13:44

v5 只塞了一个信号进 footer(等工具)。下一步 v6 把”工具调用次数 + 名称 + 主题循环”等更多信号搬到独立 widget。widget 比 footer 适合多信号并存——footer 适合一条总结状态,widget 适合多行陈列。

可执行步骤

  • 写一个 ext:监听到 onToolCall 事件时,在 footer 写 waiting for tools,onModelOutput 时清理
  • 同时叠加 v2 的 minimal footer 一起 stacking,验证 footer 可以同时显示多个信号(“claude set 4.6 + 等待工具”)
  • 跑一条会让 agent 调多次工具的 prompt,记录 “waiting for tools” 在每条提示出现 / 消失的节奏
  • (后续)v6 直接把”工具调用次数”做成 widget

关联

  • 进阶(同信号搬到 widget):本片 08-v6-Tool-Counter-Widget.md — 同一工具计数信号在 widget 里演化成完整面板
  • 互补(同一工具信号在另一场景):本片 09-v7-Subagent-Widget.md — v7 把 widget 借给 subagent 管理,同 widget 抽象的另一面
  • 互补(可见性主张):CMUX 实测 — 同样主张 agent 状态必须可见

一手来源与延伸

  • Pi extension 文档:https://pi.dev/
  • 视频 13:44-14:38(v5 Tool Counter 演示)

术语

  • Tool waiting state:agent 在 tool call 期间(选工具 / 构造参数)的等待状态,在 v5 里被显式暴露
  • Lifecycle event:Pi ext 可监听的 hook 系列:onPrompt / onToolCall / onToolResult / onModelOutput / onRender 等

金句

You can really customize it to make it your own. (14:14) — footer 全层可定制的一句话总结。

立场与利益

  • 利益中性:状态行可见化是工程设计,无直接挂商品

价值定位

本片目标学习者的价值:

  • 适合谁:想让 agent 状态对自己透明可调试的工程师
  • 解决什么:agent 当前是不是卡在某处(等工具、等模型、等输入)要直观可见——这是 agentic engineering 的基础可见性原则
  • 认知 vs 实操:实操 + 轻度认知 — 监听 lifecycle event + 改 footer
  • 与本片其他章节重叠:同 widget 模式铺垫

自检问题

  1. “waiting for tools” 状态对应 agent 的哪一段动作? 答案:模型正在构造下一次工具调用(选哪个工具 + 构造什么参数)——这是决策点而非打字点。回跳 13:44
  2. v5 与 v6 的关键演化差异是什么? 答案:v5 把”等工具”塞进 footer,v6 直接升级成独立 widget——footer 适合一条总结状态,widget 适合多信号陈列。回跳 13:44
  3. lifecycle event 在 Pi ext 中可以监听的有哪些? 答案:onPrompt、onToolCall、onToolResult、onModelOutput、onRender 等,v5 用 onToolCall 在 footer 显示状态。回跳 13:44