06｜pi-coding-agent：把通用能力装配成“可用的编程代理产品”

这篇写什么

讨论 packages/coding-agent 这一层如何把 pi-ai 与 pi-agent-core 装配成一个面向编程场景的真实产品：它关心 session、默认工具集、动态 prompt、扩展点，而不只是抽象。

先说结论

pi-coding-agent 的定位更准确地说是：面向编程场景的 agent 产品装配层。如果前两层分别是：pi-ai：统一模型调用pi-agent-core：统一 agent loop那么第三层做的是：把模型、runtime、prompt、tools、session、settings、extensions 与交互模式一起装配成一个终端里的 coding product。

为什么第三层才开始真正绑定编程场景

前两层更通用；第三层必须选择一个明确落点。这里的落点非常清晰：代码仓库工作流。默认工具集（read/write/edit/bash）就是最直接的场景宣言。

第三层的中心：会话（session）是一等公民

很多简单 agent 只把历史当数组；但在 coding 场景里，session 本身就是产品能力：持续对话与上下文模型切换、thinking 设置工具调用与命令历史compaction / retry 等运行策略这种设计让 agent 更像长期工作的开发会话，而不是单轮问答。

动态 system prompt：不是一段死文本

第三层的 prompt 往往是“编译产物”，来源包括：默认 coding prompt当前启用 tools（以及 tool prompt snippet/guideline）项目上下文文件（例如 AGENTS.md）skills / extensions用户追加的 system prompt当前环境信息（日期、工作目录等）这使得“主 agent”不只是 prompt，而是一个动态装配出来的产品对象。

核心克制、扩展很强

一个值得借鉴的产品哲学是：默认内核小、职责清晰但扩展点丰富（extensions、skills、prompt templates、themes、自定义 tools/provider…）这让核心体验稳定，同时不给系统锁死。

小结

pi-coding-agent 的价值不在“再包一层”，而在把通用能力产品化：把 prompt、tools、session、settings、扩展点与交互模式组织成一个程序员能真正长期使用的编程代理。