一个Agent产品是否成熟，不只看它能完成多少任务，还要看用户是否知道它正在做什么、为什么这样做，以及出错后怎样接管。功能决定能力上限，控制权决定产品能不能真正进入工作。

假设你正在负责一款面向研发团队的AI Agent。

第一版很简单：读取文件、修改代码、运行命令。用户觉得不够，于是团队加入Plan Mode、Todo、Sub-agents、MCP、长期记忆、后台任务和权限确认。每一次迭代都有明确理由，功能列表也越来越像一款成熟产品。

但用户的疑问没有减少，反而变多了。

“它现在进行到哪一步？”

“为什么没有按刚才确认的方案执行？”

“这个操作是谁批准的？”

“任务失败后，是重来还是从中间继续？”

产品拥有了更多能力，用户却逐渐失去了对过程的把握。这是很多Agent产品从演示走向真实工作时都会遇到的问题：团队一直在设计Agent能做什么，却很少设计用户怎样理解、干预和收回它的决定权。

最近受到开发者关注的Pi Agent，恰好提供了一个反方向的样本。它主动缩小核心，把大量能力留在配置和扩展层。这个选择未必适合所有产品，却能帮助产品经理重新思考一个更重要的问题：一项能力究竟应该由产品默认决定，还是交给用户？

一、功能增加，为什么会让控制感下降？

传统工具的大部分功能是被动的。用户点击按钮，系统执行动作，操作与结果之间的关系相对清楚。

Agent不同。用户给出目标后，系统会自己拆任务、选工具、读取数据、改变环境，并根据中间结果继续行动。产品每增加一项自主能力，就等于增加了一类系统可以替用户做出的决定。

当这些决定没有被清楚呈现时，问题通常会出现在三个时刻。

第一个时刻是任务开始前。用户只说了目标，却不知道Agent准备采用什么路径，也不知道哪些数据和工具会被调用。

第二个时刻是任务执行中。Agent可能已经偏离方向，但界面只显示“正在思考”或不断滚动的执行日志，用户很难判断应该等待还是打断。

第三个时刻是任务失败后。用户看到了错误结果，却看不到错误来自目标理解、上下文、工具调用还是某个中间判断，只能重新发起一次任务。

所以，Agent产品的复杂度不只来自功能数量，还来自决策数量。一项能力越自主，产品越需要回答四件事：谁发起、谁确认、谁能中止、谁为结果负责。

二、先别问还缺什么功能，先问谁来做决定

产品团队习惯用功能清单管理需求，因为功能容易命名、排期和验收。但Agent面对的是大量非标准任务，同一个目标在不同用户手里，数据来源、执行顺序、审批要求和完成标准都可能不同。

如果每出现一种差异，产品就增加一个新入口，最后往往会得到两样东西：一套越来越重的界面，以及一组互相影响的默认规则。

更实用的做法，是先判断一项决策应该放在哪一层。

高频、稳定、错误代价高，并且需要统一体验的决策，适合进入产品核心。例如任务状态、暂停与继续、工具调用记录、失败提示和基础权限边界。

用户之间存在差异，但可以通过清楚选项表达的决策，适合放进配置层。例如模型选择、项目指令、审批节点、输出格式和成本上限。

低频、变化快、只服务少数专业场景的能力，更适合交给扩展层。例如接入一套内部发布系统、增加特定代码检查器，或者为某类团队定制一条专属工作流。

这不是简单的技术分层，而是在分配产品决策权。

三、Pi为什么敢把核心做得这么小？

按照Pi官方文档的定义，Pi是一个最小化的终端编码Agent框架。它默认交给模型的核心工具只有4个：read、write、edit和bash。

这4个工具分别负责读取环境、创建内容、修改内容和调用现有命令。它们不直接对应“生成一个页面”或“修复某类Bug”，却能被反复组合，完成大量事先没有写进功能清单的任务。

Pi同时把MCP、Sub-agents、权限弹窗、Plan Mode、内置Todo等能力留在核心之外。用户仍然能通过Extensions、Skills、Prompt Templates、Themes和Packages增加这些能力，只是产品没有替所有人固定同一套答案。

Pi的选择并不等于功能越少越好。它成立的前提是，核心足够稳定，扩展接口足够开放，目标用户也愿意承担配置成本。

真正有启发的地方在于：Pi没有把“用户需要”直接翻译成“核心必须内置”，而是先判断这项需求应该属于核心、配置还是扩展。

图1：Agent产品可以按核心能力、可配置决策和扩展工作流划分边界，制图：知序

四、同一项默认功能，对不同用户可能是价值，也可能是阻力

产品替用户做决定，本身是一种价值。问题在于，不同用户需要被替代的决策并不相同。

第一次使用Agent的新手，更关心尽快完成任务。清楚的默认流程、有限的选项和及时提示，能降低理解成本。此时让用户先配置模型、工具、权限和上下文，只会把产品复杂度提前压到用户身上。

专业用户已经有稳定工作方式。他们更在意控制执行顺序、替换工具、修改系统指令和复用团队规范。对这类用户，过度统一的默认流程会成为阻力。

企业用户还多了一层要求：个人自由度需要服从组织治理。谁能安装扩展、哪些数据可以读取、什么动作必须审批、执行记录保留多久，都需要统一规则。

因此，Agent产品很难靠一套固定界面服务所有人。更合理的方式是逐层开放：新手先获得可预测的默认体验，专业用户再进入配置层，企业管理员负责扩展、权限和审计基线。

这比“提供高级模式”更具体。它要求产品经理明确，每开放一层控制权，用户会得到什么，同时需要承担什么。

五、Agent的控制权，最后会落在上下文上

很多AI产品把控制权理解成权限弹窗。实际上，用户是否能管理Agent看到的上下文，同样决定了任务是否可控。

Pi把会话历史保存成树结构。用户可以从某个历史节点分叉，尝试另一条执行路径；会话过长时，系统可以压缩早期内容，保留后续任务需要的信息。

图2：Pi Agent用树状会话保存分支，图片来源：Pi官方Press Kit

树状会话只是其中一种形式，背后对应的是4项更普遍的产品要求。

1. 过程可见。用户知道Agent已经完成什么、正在处理什么，以及下一步准备做什么。
2. 过程可打断。用户发现方向偏离时，可以暂停任务、修改目标或撤回某个工具调用。
3. 失败可恢复。任务中断后，系统可以从可信节点继续，而不是让用户从头描述一遍背景。
4. 结果可追溯。最终输出能够关联到使用过的数据、工具、关键判断和人工确认记录。

当Agent只回答一个问题时，这些能力显得有些重；当它开始连续工作十几分钟、跨越多个系统时，它们就从辅助功能变成了核心界面。

六、自由度越高，治理越要提前出现

开放扩展能让产品快速覆盖长尾需求，也会带来新的责任。

Pi的扩展可以注册工具、监听会话事件、修改上下文和增加自定义界面。按照Extensions官方文档，扩展甚至可以拦截工具调用。这让用户拥有很高的改造空间，也意味着扩展来源、权限范围、版本变化和回滚方式都需要被认真管理。

对个人开发者来说，这可能是一笔愿意承担的成本；对企业团队来说，它会直接变成产品需求。

团队至少需要一份允许使用的扩展清单、一套统一的项目指令、明确的凭证访问规则，以及出现异常后的停用和回滚机制。否则，20个人使用的可能不是同一款Agent，而是20套行为各异的执行环境。

开放与治理并不冲突。真正的问题是，产品是否只释放了自由度，却把风险识别和善后工作全部留给用户。

七、产品经理应该看什么指标？

功能数量和对话轮次很容易统计，却很难说明Agent是否真的变得更好用。

如果产品希望提升用户的控制感，可以优先观察下面几类指标。

• 首次任务成功时间。用户从进入产品到完成第一个有效任务需要多久。它能反映默认配置是否清楚，也能暴露产品是否把太多决策提前交给了新手。
• 人工介入率。用户在哪些节点频繁暂停、修改或接管任务。介入率高不一定代表产品失败，但集中发生在同一节点，通常说明默认策略存在问题。
• 失败恢复率。任务出错后，有多少用户能够从中间状态继续完成，而不是放弃或从头开始。
• 配置复用率。用户创建的指令、工作流和扩展是否被再次使用，是否能在团队内传播。它能帮助产品判断配置层是否真正承接了差异化需求。
• 升级迁移成本。模型、工具或扩展更新后，已有工作流需要修改多少。一个高度可配置却难以维护的产品，也会逐渐消耗用户信任。

这些指标共同回答的不是“Agent运行了多少次”，而是“用户是否能够稳定地把工作交给它”。

八、做Agent产品，可以先回答这5个问题

下一次评审Agent功能时，产品团队可以先暂停讨论按钮放在哪里，回答下面5个问题。

1. 这项能力是否高频、稳定，并且需要所有用户获得一致体验？
2. 不同用户对它的执行方式是否存在明显差异？
3. 用户能否看见、修改并撤回这项能力做出的决定？
4. 它进入扩展层后，权限、审计、版本和回滚由谁负责？
5. 上线后用什么指标证明它减少了用户负担，而不是增加了新的配置工作？

这5个问题比“竞品已经做了，我们要不要跟”更难回答，却更接近Agent产品的真实门槛。

九、写在最后

Pi Agent不是所有用户的标准答案。它偏向专业开发者，也把不少配置和治理工作交给了使用者。但它提醒了产品团队一件容易被功能规划掩盖的事：产品的完整度，不等于核心里装了多少能力。

当Agent开始替用户连续做决定，产品经理需要设计的不只是功能入口，还包括决定权怎样分配、过程怎样呈现、异常怎样接管，以及自由度由什么规则约束。

功能决定Agent能走多远，控制权决定用户愿不愿意让它继续走。

作者：知序，践行AI First的产品人，关注AI产品设计、Agent工程与产品工作方式。

参考资料：

1.Pi官方文档

2.Pi Extensions文档

3.Pi官方Press Kit