探寻 Agent 架构的逻辑边界：从 pi-coding-agent 说起
前言：喧嚣中的一点思考
最近在研究 pi-coding-agent 这个开源项目时，被其极简的设计所吸引。在目前追求“大而全”、试图用一个工具解决所有开发问题的潮流中，它显得有些独特。
它没有花哨的图形界面，甚至没有内置目前备受推崇的 MCP (Model Context Protocol) 协议。这种“克制”引发了我的一系列思考：我们口中频繁提到的 Tool（工具）、Skill（技能）与 Workflow（工作流），其逻辑边界究竟在哪里？智能体架构的演化，是否正在经历某种类似操作系统内核的分化？
本文不试图定义标准，只是想分享我在调研 pi 以及对比其他重工业级架构（如 Antigravity）时的一些复盘与观察。
视角转换：作为底层支撑的架构模式
我们习惯于将 Agent 视为一个对话框，但在深入 pi 的源码后，我发现它更像是一个“微内核”式的运行时。
1. 状态管理：从历史记录到状态树
在大多数 AI 编码工具中，对话历史通常是线性的。然而 pi 采用了树状的 Session 管理（Tree-based Session）。
这种设计取舍反映了对开发过程的深刻理解：开发本质上是一个不断试错的过程。树状结构允许开发者随时回滚到某个时间点，开启一个新的分支（Fork）进行探索，而不会丢失之前的尝试。这种对 开发上下文（Context） 的管理，已经超越了单纯的“聊天历史”，更像是一种带快照功能的内存管理系统。
2. 控制机制：可编程的“内核”
pi 并没有提供复杂的配置面板，而是暴露了一套基于 TypeScript 的 Extension API。
这是一种非常有意思的哲学：它不预设你会用什么工具，也不预设你的工作流。它认为最直接的控制权应该交给开发者。通过 Hook 机制，你可以直接介入 Agent 的生命周期（如 tool_call 触发前、agent_end 结束后）。
这种“内核驱动”式的设计，比起通过 JSON-RPC 跨进程通信的通用协议，在效率和控制深度上提供了不同的可能性。
概念澄清：尝试理清 Tool, Skill 与 Workflow
在当前的 Agent 语境下，Tool, Skill 和 Workflow 这三个词经常被混用。为了更好地构建架构，我尝试对它们进行如下分层：
1. Tool (能力层)：解决“能不能”的问题
这是 Agent 的原子能力，是它操作外部世界的接口。
- 本质：Agent 的“手”。
- 例子：
read_file,bash_execute,edit_block。 - 逻辑：它应该是无状态的、纯粹的功能调用。
2. Skill (指导层)：解决“怎么做”的问题
这是通过提示词（Prompt）封装的特定任务经验。
- 本质：Agent 的“操作手册”。
- 例子：一个教 Agent “如何分析 Java 堆栈报错”的 Skill。
- 逻辑：它是一组指导方针，依赖于模型本身的推理能力。
3. Workflow (控制层)：解决“如何确保达成”的问题
这是工程化的状态控制和异常处理逻辑。
- 本质：任务的“导演”或“调度器”。
- 例子：自动化的“测试-修复-重跑”闭环逻辑。
- 逻辑：它包含状态机、条件判断和自动纠错。
观察：很多时候我们觉得智能体表现不稳定，或许是因为我们试图用“软约束”的 Skill (提示词) 去解决本该由“硬逻辑”的 Workflow (控制代码) 负责的问题。建议在架构设计时，尽可能将核心逻辑从 Prompt 中解耦，下沉到控制层。
路径分化：关于设计哲学的一些观察
在调研过程中，我发现目前的智能体架构似乎正在沿着两种不同的设计取舍演进：
1. 侧重灵活性的“轻量级内核”模式
以 pi 为代表。它并不试图在内核中内置复杂的逻辑，而是通过暴露极致的 Extension 能力，让开发者根据自己的项目需求，用代码（如 TypeScript）去编写自己的控制逻辑。
这种模式的魅力在于 高度的透明性。Agent 不是一个无法预测的黑盒，而是一个在开发者定义的规则下运行的辅助程序。
2. 侧重稳健性的“高集成度方案”
以 Antigravity 为代表。它通过内置复杂的任务调度引擎（Workflow Orchestrator）、上下文隔离机制以及目标自愈逻辑，尝试在无需人工干预的情况下完成长程任务。
这更像是一个 “自动驾驶”系统。它牺牲了一定的轻便性，但在处理跨文件、跨模块的大规模重构任务时，提供了更高的工业级成功率。
结语：在实践中寻找平衡
Agent 架构的演进远未结束，现在去定义谁是“终局方案”显然为时过早。
对我而言，最核心的收获不是找到了一个完美的工具，而是通过对比这些不同的设计哲学，理清了自己对 Tool、Skill 与 Workflow 的认知边界。
在构建自己的 Agent 工作流时，我们或许不必执着于追求最复杂的协议，而是应该问自己：我的任务核心究竟是需要更强的推理指导（Skill），还是更稳健的流程控制（Workflow）？在这个基础上，选择或构建最适合自己的那个“内核”。
注：本文仅代表个人阶段性的学习复盘，如有偏颇，欢迎探讨。