酒店摄像头检测
98.35M · 2026-03-22
@mariozechner/pi-ai@mariozechner/pi-agent-core@mariozechner/pi-coding-agent@mariozechner/pi-tui@mariozechner/pi-web-ui@mariozechner/pi-mom@mariozechner/pi / packages/pods这个仓库不是一个单一应用，而是一整套围绕 Agent 开发、LLM 接入、交互界面、会话持久化、部署与运维 的工具链。
如果用一句话概括：
它覆盖了三个层面：
在读这个仓库之前，建议先把以下概念区分清楚：
openai-responses、anthropic-messages、azure-openai-responses、openai-codex-responses、google-gemini-cli 等。gpt-5.4、claude-opus-4-6、gemini-2.5-pro。pi-ai 的职责，就是把这些差异统一成一套公共抽象。
这个仓库里“消息”不是简单字符串。
pi-ai 里，消息是 LLM 可理解的消息：user、assistant、toolResult。pi-agent-core / pi-coding-agent 里，消息会扩展成更多内部消息，例如：
bashExecutioncustombranchSummarycompactionSummary也就是说：
LLM 不直接改文件、不直接执行 shell。
它会先输出一个工具调用，例如：
read(path="src/index.ts")bash(command="npm run check")edit(path="foo.ts", ...)系统接到这个工具调用后：
toolResult这个仓库非常强调 事件流。
几乎所有关键动作都会被事件化：
这使得同一套核心逻辑可以同时支撑：
在 pi-coding-agent 里，会话不是一条线，而是一棵树。
这意味着你可以：
所以它更像“带分支的对话工作流”，而不是普通聊天记录。
graph TD
U[用户/上层应用] --> CA[pi-coding-agent]
U --> WEB[pi-web-ui]
U --> MOM[pi-mom]
U --> PODS[pi pods CLI]
CA --> AGENT[pi-agent-core]
WEB --> AGENT
MOM --> AGENT
PODS --> AGENT
AGENT --> AI[pi-ai]
CA --> TUI[pi-tui]
WEB --> AI
AI --> OPENAI[OpenAI / Azure OpenAI / OpenAI Codex]
AI --> ANTHROPIC[Anthropic]
AI --> GOOGLE[Google / Vertex / Gemini CLI]
AI --> COPILOT[GitHub Copilot]
AI --> OTHER[Groq / Mistral / xAI / OpenRouter / Bedrock / Cerebras / Minimax / Huggingface / Vercel AI Gateway / 兼容 API]
可以把它理解成：
pi-ai：统一 LLM 底座pi-agent-core：通用 agent 运行时pi-coding-agent：面向开发者的高阶产品层pi-tui / pi-web-ui / pi-mom / pi：不同交付形态| 包 | 定位 | 适合谁用 | 核心价值 |
|---|---|---|---|
@mariozechner/pi-ai | 多 provider 统一 LLM API | 需要直接对接模型的开发者 | 屏蔽 provider 差异、统一流式事件与工具调用 |
@mariozechner/pi-agent-core | 通用 agent 运行时 | 需要自己做 agent 产品的人 | 管理工具循环、状态、事件、消息转换 |
@mariozechner/pi-coding-agent | 终端 coding agent + SDK | 想直接用现成 coding harness 的开发者 | 会话管理、扩展系统、技能、模板、会话树 |
@mariozechner/pi-tui | 终端 UI 框架 | 做交互式 CLI/TUI 的开发者 | 差量渲染、键盘输入、编辑器、图片 |
@mariozechner/pi-web-ui | AI Chat Web 组件库 | 想做浏览器聊天界面的人 | ChatPanel、附件、artifact、浏览器存储 |
@mariozechner/pi-mom | Slack Agent | 想把 agent 接到 Slack 工作流的人 | 每频道独立上下文、自管理技能、沙箱执行 |
@mariozechner/pi | GPU Pod/vLLM 运维 CLI | 自己部署模型服务的人 | Pod 管理、模型启动、OpenAI 兼容接口 |
下面这张图是整个仓库最关键的总流程图。
flowchart TD
A[用户输入 Prompt] --> B{来自哪一层?}
B -->|SDK/CLI/Web/Slack| C[组装 AgentMessage]
C --> D[pi-agent-core.Agent / agentLoop]
D --> E[convertToLlm / transformContext]
E --> F[pi-ai.streamSimple 或 stream]
F --> G[Provider Adapter]
G --> H[远端模型]
H --> I[流式返回 assistant 事件]
I --> J{是否有 toolCall?}
J -->|否| K[形成 AssistantMessage]
J -->|是| L[执行工具]
L --> M[生成 ToolResultMessage]
M --> D
K --> N[事件广播给 UI / SDK]
N --> O[会话持久化 / 渲染 / 存储]
@mariozechner/pi-ai如果你直接接每家大模型，你会遇到这些差异：
pi-ai 的目标是：
packages/ai/src/types.ts 定义了这套系统的基础语言。
关键类型包括：
Api / KnownApi：API 协议类型（openai-responses、anthropic-messages、azure-openai-responses、openai-codex-responses、google-gemini-cli 等）Provider / KnownProvider：供应商类型（anthropic、openai、google、azure-openai-responses、github-copilot、groq、cerebras、openrouter 等 22 种）Model<TApi>StreamOptions / SimpleStreamOptions / ProviderStreamOptionsContextMessageUserMessageAssistantMessageToolResultMessageTool<TParameters>AssistantMessageEvent / AssistantMessageEventStreamThinkingLevel："minimal" | "low" | "medium" | "high" | "xhigh"ThinkingBudgetsStopReason："stop" | "length" | "toolUse" | "error" | "aborted"Usage：token 与成本跟踪CacheRetention / TransportOpenAICompletionsCompat / OpenAIResponsesCompat：兼容模式配置OpenRouterRouting / VercelGatewayRouting：路由偏好最核心的消息内容块包括：
TextContentThinkingContentImageContentToolCallpi-ai 的统一调用入口从 packages/ai/src/stream.ts 看，核心入口只有四个：
stream()：最底层、按具体 API 类型走complete()：一次性拿完整结果streamSimple()：统一接口，最常用completeSimple()：统一接口的完整结果版本可以理解为：
packages/ai/src/providers/ 里放的是各家 provider 适配器，例如：
anthropic.tsopenai-responses.tsopenai-completions.tsazure-openai-responses.ts — Azure OpenAIopenai-codex-responses.ts — OpenAI Codexgoogle.tsgoogle-vertex.tsgoogle-gemini-cli.ts — Google Gemini CLIamazon-bedrock.tsmistral.ts此外还有一些共享/工具文件：
google-shared.ts — Google 系 provider 共享逻辑openai-responses-shared.ts — OpenAI Responses 系共享逻辑github-copilot-headers.ts — GitHub Copilot 鉴权头simple-options.ts — 公共选项工具transform-messages.ts — 消息格式转换register-builtins.ts — 内置 provider 注册与懒加载每个 provider 适配器本质上做三件事：
Context 转换成该 provider 的请求体AssistantMessageEventpi-ai 的事件流模型AssistantMessageEvent 是理解整个系统的第一关键。
它不是“只给你一个最终字符串”，而是给你一个增量构建过程：
starttext_starttext_deltatext_endthinking_startthinking_deltathinking_endtoolcall_starttoolcall_deltatoolcall_enddoneerror这意味着上层可以非常细地控制渲染：
pi-ai 的内部工作流sequenceDiagram
participant App as 上层调用者
participant AI as pi-ai
participant Provider as Provider Adapter
participant Remote as 远端 LLM API
App->>AI: streamSimple(model, context, options)
AI->>AI: 根据 model.api 找到 provider
AI->>Provider: provider.streamSimple(...)
Provider->>Remote: 发起 HTTP/SSE/WebSocket 请求
Remote-->>Provider: 流式 chunk
Provider-->>AI: 统一 AssistantMessageEvent
AI-->>App: start/text_delta/toolcall_delta/done/error
packages/ai/src/models.ts 提供：
getModel(provider, modelId) — 获取特定模型getModels(provider) — 获取某 provider 下所有模型getProviders() — 获取所有已知 provider 列表calculateCost(model, usage) — 计算 token 使用成本supportsXhigh(model) — 判断模型是否支持 xhigh thinking levelmodelsAreEqual(a, b) — 比较两个模型是否相同Model<TApi> 本身会携带：
这使得上层能在运行前就知道：
pi-ai 明确聚焦于 支持工具调用的模型。这非常关键，因为整个上层生态都是围绕 agentic workflow 构建的。
换句话说：
按顺序看：
packages/ai/README.mdpackages/ai/src/types.tspackages/ai/src/stream.tspackages/ai/src/models.tspackages/ai/src/api-registry.tspackages/ai/src/env-api-keys.tspackages/ai/src/providers/register-builtins.tspackages/ai/src/providers/anthropic.ts@mariozechner/pi-agent-core如果说 pi-ai 负责“和模型说话”，那么 pi-agent-core 负责：
Agent 类：面向日常使用的高层 APIagentLoop() / agentLoopContinue()：底层循环函数Agent 解决的是什么问题packages/agent/src/agent.ts 中的 Agent 类主要负责：
AgentStateabort()、waitForIdle() 等控制能力AgentState 是什么它本质上是 agent 运行时的当前快照，典型包括：
systemPromptmodelthinkingLeveltoolsmessagesisStreamingpendingToolCallsstreamMessage — 当前流式输出的消息errorAgentMessage 为什么比 LLM Message 更宽在 agent-core 里，AgentMessage 是可扩展的。基础消息来自 pi-ai，但允许应用侧通过 declaration merging 注入自己的消息类型。
这样做的意义是：
convertToLlm() 过滤或转换这是一种很好的架构分层：
下面是 agentLoop() 的核心思想：
agent_start 和 turn_startstreamAssistantResponse() 获取 assistant 流agent_endsequenceDiagram
participant User as 调用方
participant Agent as pi-agent-core.Agent
participant CoreLoop as agentLoop
participant AI as pi-ai
participant Tool as Tool Executor
User->>Agent: prompt("修复这个 bug")
Agent->>CoreLoop: agentLoop(messages, context, config)
CoreLoop->>AI: streamSimple(model, llmContext)
AI-->>CoreLoop: text_delta / toolcall_delta / done
CoreLoop-->>Agent: message_update
alt assistant 触发工具
CoreLoop->>Tool: execute(toolCall)
Tool-->>CoreLoop: toolResult
CoreLoop->>AI: 带 toolResult 再次请求
AI-->>CoreLoop: 新一轮 assistant 输出
end
CoreLoop-->>Agent: agent_end
Agent-->>User: 事件完成
executeToolCalls() 这段逻辑非常关键：
toolCallAgentToolvalidateToolArguments() 校验参数tool_execution_updateToolResultMessage还有一个很实用的设计：
这使得 agent 在长工具链里仍然可打断。
steer 和 followUp 的意义这是 Agent 相较于简单聊天 SDK 的一个重要增强。
steer：尽快打断当前工作流；当前工具结束后插入新消息，剩余工具可以被跳过followUp：等 agent 当前工作全部结束后，再进入下一轮这让交互体验更像“指挥一个正在干活的 agent”，而不只是连续对话。
transformContext 和 convertToLlm 很重要这两个钩子是整个系统可扩展性的核心。
transformContext(messages)：在发给 LLM 前对内部上下文做再加工convertToLlm(messages)：把内部消息裁剪成真正兼容 LLM 的消息很多上层能力都依赖它们：
packages/agent/README.mdpackages/agent/src/types.tspackages/agent/src/agent-loop.tspackages/agent/src/agent.ts@mariozechner/pi-coding-agentpi-coding-agent 是整个仓库里最复杂、也最像“最终产品”的包。
它不是简单在 agent-core 外面套一层 CLI，而是叠加了很多高级能力：
AgentSession 是怎么装出来的packages/coding-agent/src/core/sdk.ts 中的 createAgentSession() 是总装厂。
graph TD
A[createAgentSession] --> B[AuthStorage]
A --> C[ModelRegistry]
A --> D[SettingsManager]
A --> E[SessionManager]
A --> F[DefaultResourceLoader]
A --> G[Agent]
A --> H[AgentSession]
F --> F1[Extensions]
F --> F2[Skills]
F --> F3[Prompt Templates]
F --> F4[Themes]
F --> F5[AGENTS / Context Files]
F --> F6[System Prompt Fragments]
H --> G
H --> E
H --> D
H --> C
H --> F
createAgentSession() 里到底做了什么按源码顺序，大致是：
cwd 和 agentDirAuthStorageModelRegistrySettingsManagerSessionManagerResourceLoader，加载 extensions / skills / prompts / themes / context filesAgentAgentAgentSessionAgentSession 是真正的核心抽象packages/coding-agent/src/core/agent-session.ts 文件顶部自己就写得很清楚：
它是各 run mode 共享的核心抽象，负责：
也就是说：
prompt() 的处理链路非常关键AgentSession.prompt() 的顺序值得重点理解：
streamingBehavior 入队before_agent_startagent.prompt()这个顺序非常体现“产品层”的设计思路：
ResourceLoader 是产品可扩展性的资源中心DefaultResourceLoader 可以统一发现和加载：
这相当于为 pi-coding-agent 建了一套“资源发现协议”。
packages/coding-agent/src/core/tools/index.ts 默认内置七类工具：
read — 读取文件bash — 执行 shell 命令edit — 编辑文件（内部使用 edit-diff.ts 实现 diff 算法）write — 写入文件grep — 搜索文件内容find — 搜索文件路径ls — 列出目录此外还有辅助模块：
truncate.ts — 输出截断工具path-utils.ts — 路径处理工具工具组合通过 codingTools 和 readOnlyTools 导出：
codingTools = [read, bash, edit, write] — 默认 coding 模式readOnlyTools = [read, grep, find, ls] — 只读模式还提供了工厂函数 createCodingTools(cwd) / createReadOnlyTools(cwd) / createAllTools(cwd) 用于自定义工作目录。
这是非常合理的默认分层：
packages/coding-agent/src/core/model-resolver.ts 做了不少工作：
provider/modelIdmodel:thinkingLevel 语法比如它会优先：
claude-sonnet-4-5此外，源码里还维护了 defaultModelPerProvider，为各 provider 给出默认模型。
packages/coding-agent/docs/session.md 说明得很完整：session 文件是 JSONL，每行一个对象，靠 id / parentId 形成树。
这样做的好处是：
graph TD
A[session header] --> B[msg 1]
B --> C[msg 2]
C --> D[msg 3]
C --> E[branch msg 1]
E --> F[branch msg 2]
除了基本消息，还会保存：
因此 session 文件不是“纯聊天日志”，而更像：
packages/coding-agent/docs/compaction.md 详细说明了 compaction 机制。
触发条件大致是：
contextTokens > contextWindow - reserveTokens
默认思路：
flowchart TD
A[检测上下文 token 使用量] --> B{是否超过阈值?}
B -->|否| C[继续正常对话]
B -->|是| D[向后遍历找到 cut point]
D --> E[收集待总结消息]
E --> F[序列化会话为摘要输入]
F --> G[调用模型生成结构化 summary]
G --> H[写入 CompactionEntry]
H --> I[重建上下文: summary + kept messages]
当你在 /tree 里切到另一个分支时，系统可以把“你离开的那条分支”总结成一条 branch summary 注入新分支。
这样切换分支不会完全丢失语义上下文。
sequenceDiagram
participant User as 用户
participant Session as SessionManager
participant Summ as Branch Summarizer
participant Agent as AgentSession
User->>Agent: /tree 导航到另一个分支
Agent->>Session: 找 common ancestor
Session-->>Agent: 需要被总结的旧分支条目
Agent->>Summ: 生成 branch summary
Summ-->>Session: 写入 BranchSummaryEntry
Session-->>Agent: 新分支上下文已重建
pi-coding-agent 的灵魂packages/coding-agent/docs/extensions.md 展示了非常强的扩展模型。
扩展可以：
flowchart TD
A[pi 启动] --> B[加载扩展]
B --> C[session_start]
C --> D[用户输入]
D --> E[input 事件]
E --> F[技能/模板展开]
F --> G[before_agent_start]
G --> H[agent_start]
H --> I[context]
I --> J[before_provider_request]
J --> K[LLM 输出]
K --> L{tool call?}
L -->|是| M[tool_call]
M --> N[tool_execution_start/update/end]
N --> O[tool_result]
O --> I
L -->|否| P[turn_end]
P --> Q[agent_end]
除了上面重点拆解的模块，packages/coding-agent/src/core/ 下还有不少重要基础设施：
| 模块 | 说明 |
|---|---|
event-bus.ts | 统一事件总线系统，所有事件订阅/发布的基础 |
slash-commands.ts | 内置斜杠命令系统（/help、/model、/tree 等） |
system-prompt.ts | 系统提示词构建逻辑 |
bash-executor.ts | Bash 执行器，支持操作钩子 |
exec.ts | 进程执行工具 |
auth-storage.ts | 凭证存储管理（API Key、OAuth） |
settings-manager.ts | 设置管理器（compaction、retry、terminal 等配置） |
diagnostics.ts | 资源诊断系统 |
keybindings.ts | 键盘快捷键配置 |
prompt-templates.ts | Prompt 模板展开 |
skills.ts | 技能加载与管理 |
messages.ts | 消息类型与转换 |
defaults.ts | 默认配置值 |
package-manager.ts | Pi 包管理（扩展/技能/模板/主题的分发） |
footer-data-provider.ts | 状态栏数据提供 |
timings.ts | 性能计时工具 |
resolve-config-value.ts | 配置值解析 |
extensions/ 目录下有完整的扩展基础设施：
types.ts — 扩展事件类型定义loader.ts — 扩展加载器runner.ts — 扩展运行时与事件分发wrapper.ts — 工具包装器（用于扩展拦截工具调用）compaction/ 目录下：
compaction.ts — 核心压缩逻辑branch-summarization.ts — 分支摘要生成utils.ts — 压缩工具函数export-html/ 目录提供了将会话导出为独立 HTML 文件的能力：
index.ts — 导出入口tool-renderer.ts — 工具结果渲染ansi-to-html.ts — ANSI 终端颜色转 HTMLtemplate.html / template.css / template.js — 完整的交互式 HTML 模板src/modes/ 目录下定义了三种运行模式：
interactive/ — 交互式 TUI 模式（包含 18+ 个专用 UI 组件）print-mode.ts — 非交互式输出模式rpc/ — RPC 模式（支持 JSONL 协议，文档见 docs/rpc.md）因为 AgentSession 已经把最难的东西封装好了：
所以你完全可以不使用官方 TUI，只用 SDK 把它嵌入：
packages/coding-agent/README.mdpackages/coding-agent/examples/README.mdpackages/coding-agent/examples/sdk/README.mdpackages/coding-agent/src/core/sdk.tspackages/coding-agent/src/core/agent-session.tspackages/coding-agent/src/core/session-manager.tspackages/coding-agent/docs/session.mdpackages/coding-agent/docs/compaction.mdpackages/coding-agent/docs/extensions.mdpackages/coding-agent/docs/rpc.mdpackages/coding-agent/docs/custom-provider.mdpackages/coding-agent/src/core/model-resolver.ts@mariozechner/pi-tui它不是一个专门服务于 pi 的私有 UI 层，而是一个相对独立的终端 UI 框架。
它强调：
很多 agent CLI 的问题，不在模型，而在交互体验：
pi-tui 正是在解决这些“工程上很烦，但决定体验”的问题。
从 packages/tui/src/index.ts 可以看到：
TUIContainerTextEditorMarkdownSelectListSettingsListImageProcessTerminalgraph TD
A[Terminal] --> B[TUI]
B --> C[Container]
C --> D[Text / Markdown / Editor / Lists]
B --> E[Key Input Parser]
B --> F[Diff Renderer]
B --> G[Overlay / Focus 管理]
如果你只是想理解 agent 主逻辑，可以先不深挖。
但如果你想：
那它就很值得细读。
@mariozechner/pi-web-ui这个包的定位非常清晰：
graph TD
A[ChatPanel] --> B[AgentInterface]
A --> C[ArtifactsPanel]
B --> D[Agent from pi-agent-core]
B --> E[Dialogs]
B --> F[Message Components]
A --> G[AppStorage]
G --> H[SettingsStore]
G --> I[ProviderKeysStore]
G --> J[SessionsStore]
G --> K[CustomProvidersStore]
G --> L[IndexedDBStorageBackend]
ChatPanel 和 AgentInterface 分层ChatPanel：高层整合组件，适合快速搭界面AgentInterface：更底层，适合你自己拼布局这是很典型的“框架层 + 组件层”分工。
浏览器环境和 CLI 最大不同在于：
这个包把这些问题都系统性处理了，而不是只给一个聊天框。
@mariozechner/pi-mommom 是一个接到 Slack 上的 agent worker。
但它不是简单“把 LLM 接到 Slack”。
它的关键设计是：
每个 channel 或 DM 都有自己的目录，里面会存：
log.jsonl：原始消息历史context.jsonl：给模型使用的上下文MEMORY.mdattachments/scratch/skills/这意味着 mom 更像一个“按频道划分的长期驻留 agent worker”。
sequenceDiagram
participant Slack as Slack
participant Mom as pi-mom
participant Store as Channel Workspace
participant Agent as Agent Runtime
participant Tools as Bash/File Tools
Slack-->>Mom: 新消息 / @mention / DM
Mom->>Store: 追加 log.jsonl
Mom->>Store: 同步 context.jsonl
Mom->>Store: 读取 MEMORY.md / attachments
Mom->>Agent: 构造请求并运行 agent
Agent->>Tools: 读文件 / 执行 bash / 写文件
Tools-->>Agent: tool results
Agent-->>Mom: 流式结果
Mom-->>Slack: 主回复 + 线程细节
pi-coding-agent 的关系它并没有重复发明一套 agent 栈，而是建立在已有能力之上：
pi-agent-core/pi-ai 做 agent 与模型交互pi-coding-agent 的思路处理技能、工作区、自管理生态它展示了一种“真实工作流中的 agent 应用”长什么样：
如果你以后想做企业内部 agent，这个包非常值得研究。
@mariozechner/pi / packages/pods很多时候你不是只想调用云 API，而是想：
packages/pods 就是为这个场景设计的。
从 packages/pods/src/cli.ts 看，主要能力有：
pi pods setuppi podspi pods activepi pods removepi shellpi sshpi startpi stoppi listpi logspi agentflowchart TD
A[准备 GPU Pod] --> B[pi pods setup]
B --> C[安装/配置 vLLM]
C --> D[配置模型存储路径]
D --> E[pi start <model> --name <name>]
E --> F[暴露 OpenAI-compatible endpoint]
F --> G[pi agent <name> 或外部客户端接入]
pi agent <name> 这件事很关键：
尤其是对于：
这些只有在 agent 场景里才容易暴露问题。
这是整个仓库最值得学习的设计之一。
统一事件流让同一套核心逻辑能被多种前端消费：
这是另一个关键点。
这让系统既灵活，又不会把内部脏数据直接塞进模型。
pi-coding-agent 没把扩展、技能、模板、主题写死在代码里，而是通过 ResourceLoader 做统一发现。
好处：
很多 agent 产品忽略了一个事实：
Pi 的 session tree 设计，是整个项目最有辨识度的架构点之一。
这两个机制一起解决了长会话系统的两个核心问题：
通过扩展系统，pi-coding-agent 支持注册自定义 model provider（见 docs/custom-provider.md）。这意味着你可以：
packages/coding-agent/docs/packages.md 描述了 Pi Packages 系统：可以通过 npm 或 git 分发和安装扩展、技能、模板、主题。
export-html/ 模块支持将会话导出为独立的交互式 HTML 文件，包含完整的 ANSI 颜色渲染和主题支持。
这个仓库整体不是走”单体超大框架”路线，而更像：
所以它非常适合学习”如何设计可演进的 Agent 系统”。
README.mdpackages/ai/README.mdpackages/agent/README.mdpackages/coding-agent/README.mdpackages/ai/README.mdpackages/agent/README.mdpackages/coding-agent/examples/sdk/README.mdpackages/coding-agent/docs/sdk.mdpackages/coding-agent/src/core/sdk.tspackages/coding-agent/src/core/agent-session.tspackages/coding-agent/README.mdpackages/coding-agent/docs/session.mdpackages/coding-agent/docs/compaction.mdpackages/coding-agent/docs/extensions.mdpackages/tui/src/index.tspackages/coding-agent/src/core/agent-session.tspackages/coding-agent/src/core/session-manager.tspi-aipi-agent-corepi-web-ui 或自己写 UIpi-coding-agent 学资源、会话、扩展系统packages/coding-agent/docs/rpc.mdpackages/coding-agent/docs/json.mdpackages/coding-agent/src/modes/rpc/packages/coding-agent/examples/sdk/README.mdpi-ai 接一个模型目标：理解统一 LLM 抽象。
你应该练到：
streamSimple()text_deltatoolcall_deltapi-agent-core 写一个最小工具型 agent目标：理解 tool loop。
你应该练到：
read_file 或 get_time 工具tool_execution_* 事件steer()pi-coding-agent SDK 搭一个简化版 CLI目标：理解产品层抽象。
你应该练到：
createAgentSession()目标：理解生态扩展点。
建议做：
/hello 命令目标：理解长会话治理。
你应该看懂：
firstKeptEntryIdBranchSummaryEntrycommon ancestor下面这份索引适合你边看边跳：
README.mdpi-aipackages/ai/README.mdpackages/ai/src/types.ts — 核心类型定义packages/ai/src/stream.ts — 统一调用入口packages/ai/src/models.ts — 模型注册与查询packages/ai/src/api-registry.ts — API 提供者注册表packages/ai/src/env-api-keys.ts — 环境变量 API Key 读取packages/ai/src/providers/register-builtins.ts — 内置 provider 注册packages/ai/src/providers/anthropic.tspackages/ai/src/providers/openai-responses.tspackages/ai/src/providers/azure-openai-responses.tspackages/ai/src/providers/openai-codex-responses.tspackages/ai/src/providers/google.tspackages/ai/src/providers/google-vertex.tspackages/ai/src/providers/google-gemini-cli.tspackages/ai/src/providers/amazon-bedrock.tspackages/ai/src/providers/mistral.tspi-agent-corepackages/agent/README.mdpackages/agent/src/types.tspackages/agent/src/agent-loop.tspackages/agent/src/agent.tspi-coding-agent核心源码：
packages/coding-agent/README.mdpackages/coding-agent/examples/README.mdpackages/coding-agent/examples/sdk/README.mdpackages/coding-agent/src/core/sdk.ts — 总装工厂packages/coding-agent/src/core/agent-session.ts — 核心会话抽象packages/coding-agent/src/core/session-manager.ts — 会话持久化packages/coding-agent/src/core/model-resolver.ts — 模型解析packages/coding-agent/src/core/model-registry.ts — 模型注册表packages/coding-agent/src/core/resource-loader.ts — 资源发现packages/coding-agent/src/core/tools/index.ts — 工具注册packages/coding-agent/src/core/event-bus.ts — 事件总线packages/coding-agent/src/core/auth-storage.ts — 凭证存储packages/coding-agent/src/core/settings-manager.ts — 设置管理packages/coding-agent/src/core/slash-commands.ts — 斜杠命令packages/coding-agent/src/core/system-prompt.ts — 系统提示词packages/coding-agent/src/core/extensions/ — 扩展系统packages/coding-agent/src/core/compaction/ — 压缩系统packages/coding-agent/src/core/export-html/ — HTML 导出文档（24 篇）：
packages/coding-agent/docs/sdk.md — SDK 使用packages/coding-agent/docs/session.md — 会话与树packages/coding-agent/docs/compaction.md — 上下文压缩packages/coding-agent/docs/extensions.md — 扩展开发packages/coding-agent/docs/rpc.md — RPC 模式协议packages/coding-agent/docs/custom-provider.md — 自定义 Providerpackages/coding-agent/docs/models.md — 模型配置packages/coding-agent/docs/providers.md — Provider 配置packages/coding-agent/docs/settings.md — 设置系统packages/coding-agent/docs/skills.md — 技能系统packages/coding-agent/docs/themes.md — 主题系统packages/coding-agent/docs/keybindings.md — 快捷键packages/coding-agent/docs/prompt-templates.md — Prompt 模板packages/coding-agent/docs/tree.md — 会话树导航packages/coding-agent/docs/json.md — JSON 输出模式packages/coding-agent/docs/packages.md — Pi 包管理packages/coding-agent/docs/shell-aliases.md — Shell 别名packages/coding-agent/docs/development.md — 开发指南packages/coding-agent/docs/tui.md — TUI 文档packages/coding-agent/docs/terminal-setup.md — 终端配置packages/coding-agent/docs/windows.md — Windows 配置packages/coding-agent/docs/tmux.md — tmux 配置packages/coding-agent/docs/termux.md — Termux 配置pi-tuipackages/tui/README.mdpackages/tui/src/index.tspackages/tui/src/tui.tspackages/tui/src/components/editor.tspi-web-uipackages/web-ui/README.mdpackages/web-ui/src/index.tspackages/web-ui/src/ChatPanel.tspackages/web-ui/src/components/AgentInterface.tspackages/web-ui/src/storage/app-storage.tspackages/web-ui/src/storage/stores/settings-store.tspackages/web-ui/src/storage/stores/provider-keys-store.tspackages/web-ui/src/storage/stores/sessions-store.tspackages/web-ui/src/storage/stores/custom-providers-store.tspackages/web-ui/src/storage/backends/indexeddb-storage-backend.tspi-mompackages/mom/README.mdpackages/mom/src/main.tspackages/mom/src/slack.tspackages/mom/src/agent.tspackages/mom/src/events.tspackages/mom/src/sandbox.tspi / podspackages/pods/README.mdpackages/pods/src/cli.tspackages/pods/src/commands/models.tspackages/pods/src/commands/pods.tspackages/pods/src/commands/prompt.ts如果你读到最后，建议把整个仓库记成下面这句话：
再换一种更工程化的说法：
graph LR
A[LLM 接入] --> B[Agent Runtime]
B --> C[Session / Tools / Extensions / Skills]
C --> D[TUI]
C --> E[Web UI]
C --> F[Slack Bot]
C --> G[GPU Pod Deployment]
只要你始终记住这条主线，读这个仓库就不容易迷路。
