设想一个投放任务：
“帮我看看这个月消耗为什么下降，顺便把异常计划整理出来；如果问题明确，就批量调整预算。”
这句话看起来可以交给 Agent 一次做完，实际包含四类不同工作：
- “为什么下降”需要补充背景、澄清目标；
- “哪些计划异常”需要筛选、对比和查看趋势；
- “整理出来”可能需要批量拉数和定时执行；
- “调整预算”涉及资金和业务风险，必须先看影响范围再确认。
如果把四件事都塞进聊天框，用户会在消息里反复描述筛选条件、核对数字、寻找进度。如果全部做成页面，又会让批量和重复任务变成一轮轮点击。
我的判断是：GUI、CLI、Chat 不是三代产品。GUI 优化识别和直接操作，CLI 优化表达密度和重复执行，Chat 优化目标协商。Agent 的价值不是消灭其中任何一种，而是根据任务阶段完成转换。
GUI、CLI、Chat 各替用户省什么
GUI 的优势不是“有图形”，而是把对象、选项、动作和状态放到用户眼前。
当用户需要从几十个计划中筛选异常项、比较趋势、录入精确预算、查看任务进度时，GUI 让回忆变成识别。用户不用记住每个字段名和合法值，可以直接看到哪些选项可用、哪些数据发生变化。
CLI 的优势也不是“看起来专业”，而是压缩稳定动作。一个操作一旦满足三个条件——规则稳定、需要反复执行、结果可以校验——命令或 API 就比页面点击更适合。它能批量处理、组合步骤、保存参数，也能交给 Agent 或定时任务调用。
Chat 解决的是另一类问题：目标还不是路径。比如“最近投放表现不对，帮我找原因”，系统需要先理解用户关心的时间、账户和判断口径，再决定调用哪些能力。这个阶段若直接甩出一张大表，用户反而要自己重新完成问题拆解。
A2UI 在这里承担的角色很有限，也很明确：目标逐渐清晰后，Agent 可以动态选择合适的 GUI。它不负责替代批处理接口，也不意味着每一步都要生成一块新界面。
不要只问任务“复杂不复杂”
“复杂任务做 GUI，简单任务做 CLI”是一个不够用的判断。
复杂可能来自不同地方：
- 用户还没想清楚目标；
- 合法选项太多，需要比较；
- 步骤很长，但每次完全相同；
- 动作本身高风险，需要复核。
第一种更需要 Chat，第二种更需要 GUI，第三种更适合 CLI/API，第四种则需要可检查的确认界面和业务审计。只用“复杂度”一个词，会把四种问题混在一起。
需求评审时，我更建议看六个维度。
1. 任务频率
低频任务的问题是用户每次回来都要重新学习，因此需要可发现性和引导。高频任务的问题是重复步骤太多，因此需要批量能力或自动化。
但高频不自动等于 CLI。计划诊断可能每天都做，却仍然依赖图表和异常对比；更合适的方案是 GUI 负责判断，CLI/API 负责重复取数。
2. 复杂度来自哪里
意图不确定，用对话澄清；选项和关系复杂，用界面呈现；规则稳定但步骤多，用命令压缩；风险高，用结构化确认。
产品经理需要拆出复杂度来源，不能用一个“智能助手”入口把它们重新包起来。
3. 可发现性
GUI 让用户看见系统能做什么，适合新手和低频用户。CLI 要求用户知道能力名称、参数和语法，适合熟悉业务的专家，也适合由 Agent 代为调用。
Chat 看似不需要学习，但空白输入框同样有门槛：用户必须先猜到系统会什么，再组织成一句准确的话。因此 Chat 需要示例、上下文和可转入 GUI 的出口，不能只留一个空框。
4. 可审计性
GUI 更适合操作前审计：展示影响对象、参数变化、Diff 和风险提示。CLI 更适合复现输入：同一条命令、同一组参数可以保存和重跑。
两者都不等于完整审计。确认弹窗只能证明用户点过确认，命令历史只能证明有人发起过请求。真正的业务审计还要记录身份、时间、参数、影响对象、权威结果和撤销状态。
因此，可审计性不是 GUI 或 CLI 的固有胜负，而是界面与动作账本的配合方式。
5. 批量效率
少量对象、需要逐项判断时，表格多选和批量操作已经够用。对象很多、规则稳定且可组合时，CLI/API 才能真正降低成本。
一个实用分界是：用户在页面上完成一次操作后，是否还会按同样规则做十次、每天做一次，或交给另一个系统继续做。如果答案是会，就应该考虑沉淀为可复用任务，而不是继续堆按钮。
6. 用户角色
同一个能力不应只按“平均用户”设计。
- 业务操作者需要看见对象、规则和当前状态；
- 专家运营需要稳定工作台，也需要批量入口；
- 管理者更关心结果、异常、影响范围和审批；
- 技术人员需要可组合、可复现的 CLI/API；
- Agent 需要结构化能力，而不是模仿人类点击页面。
信息密度因角色而变。只提供 GUI 会限制自动化，只提供 CLI 会把学习成本推给业务用户，只提供 Chat 则会把精确操作变成反复协商。
什么时候根本不需要界面
Agent 产品很容易把每个能力都包装成卡片、进度条或结果页。但如果界面不会减少理解和操作成本，就不必做。
以下任务通常可以没有面向人的操作界面：
- 系统之间的结构化调用；
- 已确认规则下的定时后台任务；
- 只需要返回一个可验证结论；
- 完成后通过通知交付即可；
- 过程中没有需要人判断的节点。
没有界面不等于没有设计。后台任务仍需要权限、状态、失败处理、业务回执和审计。只是这些能力不必强迫用户全程观看。
如果任务执行十分钟，用户唯一能做的事是盯着进度动画，那么更好的设计可能是让任务后台运行，出现异常或需要决策时再通知用户。
Agent 应该做转换层
更合理的 Agent 交互不是“所有事情从此都用说的”，而是四种转换：
Chat → CLI/API
用户表达目标，Agent 补齐必要参数，生成结构化调用。适合批量拉数、定时报告和可重复的数据处理。
Chat → GUI
当目标涉及多个合法选项、精确参数或风险影响时，Agent 转换成可检查界面。用户不用继续用自然语言校对一串数字。
GUI → 可复用任务
用户在页面上完成一次筛选和处理后，可以把规则保存为任务。GUI 负责定义和预览，CLI/API 负责重复执行。
CLI/API → GUI
命令执行结果不必继续用日志轰炸用户。Agent 可以把异常转换为 Surface，让用户只处理需要判断的部分。
这四种转换有一个前提：不同入口必须共享同一权威状态、权限和动作记录。否则同一件事在 Chat 里显示成功，在页面上仍是旧状态，所谓“多入口”只会变成多套真相。
放回智投场景，应该怎么选
根据现有内部材料，可以得到一条清晰的产品分工：
- “帮我看看为什么消耗下降”适合从 Chat 开始；
- 计划筛选、趋势比较、参数复核适合 GUI；
- 批量拉数、定时任务和稳定规则执行适合 CLI/API；
- 调预算、删除、外发、跨权限和高风险批量写，必须把判断权交还给人。
最后一类不是“Agent 不够聪明”，而是业务责任不能被自然语言入口稀释。智投内部 HITL 方案已经把涉钱、不可逆、外发、跨权限、合规和高风险批量写列为强制确认项，模型和 Skill 都不能跳过。
这里需要保留证据边界：现有材料能证明这些是内部设计和规则，不能证明所有界面、命令能力和跨设备流程已经上线，也没有真实效率指标。因此本篇讨论的是选择方法，不是上线复盘。
一套可直接用于评审的七问
设计一个 Agent 能力前，可以按顺序问：
- 用户知道准确动作，还是只知道目标？
- 是否需要看见合法选项、对象关系、趋势或进度？
- 参数是否必须精确，错误是否容易发现和恢复？
- 任务是否高频、批量、可组合或需要定时运行？
- 动作是否涉钱、删除、外发、跨权限或批量写？
- 操作者是新手、业务专家、管理者、技术人员还是 Agent？
- 过程中是否存在必须由人判断或担责的节点？
对应的选择并不复杂：
- 目标不清，先用 Chat；
- 需要识别、比较、精确录入、监控或确认，提供 GUI；
- 高频、稳定、批量、可组合，提供 CLI/API；
- 没有人类决策且结果可验证，放到后台执行。
反方观点是，模型能力足够强以后，用户只要描述目标，具体命令和界面都可以隐藏。
这对低风险、易验证的纯委托任务成立。专业工作却不只有“得到结果”，还包括验证、比较、干预、复用和问责。Agent 可以隐藏执行细节，但不能隐藏用户需要承担的判断。
所以，产品经理真正要决定的不是“GUI 还是 CLI”，而是找到人机控制权的交接点：在哪个阶段让人看见什么，在哪个阶段让机器高效执行，以及什么时候必须把控制权交还给人。
系列导航
- 上一篇：03 【A2UI】聊天是否是最好的交互方式
- 下一篇：05 【A2UI】实践：模型负责理解，工程负责完成