考察点
这道题出自 javabetter 面经的 CLI 专题（「如果我是开发者，想给自己的产品做一个 CLI，应该注意什么」「传统 CLI 和现在的 CLI 有什么区别」），2026 年各家都在发 CLI 工具后成了热门题。面试官想看你有没有从「使用者」切换到「设计者」的视角：工具怎么设计模型才用得好、安全和成本怎么控。追问常往「为什么是 CLI 而不是 GUI」「工具更新了模型怎么办」走。
参考答案
先回答「为什么是 CLI」
设计之前得想清楚为什么这波 agent 都长在终端里。原因有两个。第一，终端天然给了 agent 两件最需要的东西：文件系统是它的工作空间，shell 是它的万能工具——编译、测试、git、包管理全在。GUI 应用里这些能力要一个个做集成，终端里全是现成的。第二，CLI 的输入输出天然是文本流，和 LLM 的接口形态完美匹配，模型读的、写的、说的都是文本，没有格式转换损耗。所以 CLI 不是复古，是 agent 时代的最小阻力路径。
工具设计：面向模型而不是面向人
这是设计 coding agent 和设计师工具最大的区别——你的用户是模型。几条原则：
- 少而通用。给 Read/Edit/Bash/Grep 这种原语，不要给「重构这个函数」这种大而专用的 API。通用原语的组合空间远大于专用接口的枚举空间，模型自己会编排。
- 输出结构化且克制。工具返回结果要有明确格式、有截断策略。一个 Grep 返回五千行匹配等于没返回——模型被噪声淹没。给行数限制、给摘要、给「还有更多」的提示。
- 错误信息要有指导性。模型看到「Permission denied」和看到「Permission denied: 该路径在允许清单外，可请求用户授权后重试」，后续行为完全不同。好的错误信息是给模型的下一步指令。
- 操作要幂等、可回滚。Edit 前先 Read 的约束、文件修改留 diff、危险命令要 dry-run 选项，都是为了让模型犯的错可被发现和撤销。
权限与安全
能执行 shell 的 agent 必须有权限分层。我的设计是四档：只读操作（读文件、搜索）自动放行；写操作（改文件）低风险但要可 diff 审计；命令执行按白名单分级，git status 放行、rm -rf 必拦；网络访问默认受限。再加一个 plan-only 模式，模型只能输出方案不能动手，给人一个零风险的预览通道。权限确认界面本身也是产品——要把「agent 想干什么、影响什么」用一句话讲清楚，否则用户只会无脑按 y，权限就形同虚设。
可观测与成本
agent 是黑盒循环，出问题时你必须能回放。每一轮发给模型的完整 payload、模型返回的 tool call、工具执行结果，全部落盘成 trace。badcase 复盘时直接看「模型当时看到了什么、决策了什么」，九成问题能定位到上下文没喂对或工具返回有误导。成本上要有预算控制：单任务 token 上限、轮次上限、缓存命中统计。一个死循环的 agent 一晚上能烧掉一个团队一周的预算，这不是夸张。
上下文管理
最后是把上下文当一等资源管理：项目记忆文件（CLAUDE.md / AGENTS.md）约定加载，会话超阈值自动压缩，中间产物写盘只留引用，重活派给独立上下文的子 agent。这块做不好的 agent，任务稍微一长就开始「失忆」，前面定的约定后面全违反。
可能的追问
- CLI 和 MCP、Skills 什么关系？——CLI 是 agent 的运行载体，MCP 是它接外部工具的协议，Skills 是给它装领域知识的包，三者是正交的分层，不冲突。
- 工具更新了模型不知道怎么办？——工具 schema 每轮都在 prompt 里，模型天然读到最新定义；真正的风险是行为语义变了，要靠工具版本管理和回归测试兜底。
- 用户装了一堆 CLI agent 怎么管理？——和包管理一个道理：统一配置目录、记忆文件放项目内随代码走、权限配置集中审计，别让 agent 配置散落各处失控。