CLI论点

一周内三个Hacker News讨论串。合计1,638点赞。同一结论：IDE是为人类设计的。CLI是为代理设计的。¹²³

Boris Tane的规划/执行分离模式（716点赞）完全在终端中运行。¹“通过CLI降低MCP成本”分析（304点赞）测量发现，用claude --print替代MCP工具调用可减少94%的token消耗。³ Vercel的just-bash项目（87点赞）证明，移除代理80%的工具反而使一切更快、更便宜、更可靠。⁴另一项独立基准测试发现，CLI方案在等效任务上比MCP少用35倍token。¹⁰

这个模式反复出现，因为架构本身决定了这一点。代理需要组合性、可脚本化和最小开销。CLI三者兼备。IDE三者皆无。

摘要

CLI优先的代理架构比基于MCP的方案在token开销上降低94%，运行速度快3.5倍，且可与标准Unix工具组合。规划/执行分离之所以有效，是因为CLI产出物是可移植的markdown文件，而非IDE状态。Remote Control使CLI代理可被远程监管，同时不牺牲组合性优势。每个成熟的代理系统最终都趋向终端，因为终端本就是自动化的栖息地。

规划/执行分离

Boris Tane记录了一个三阶段工作流，454位HN评论者用各自的变体验证了它：研究、规划、实现。¹关键观察：在您审阅并批准书面计划之前，绝不让代理写代码。

该工作流在每个阶段产出markdown产出物。research.md记录代码库分析。plan.md记录包含代码片段的实现策略。开发者在编辑器中审阅，添加行内注释，然后将标注过的计划连同明确指令一起发回：”先不要实现。”标注循环在写出第一行代码之前会重复一到六次。

整个循环通过终端中的claude运行。无需IDE插件。无需可视化差异工具。Markdown文件输入，markdown文件输出。这些产出物能在上下文窗口压缩中幸存，因为它们以文件形式存在，而非对话状态。

我的自主循环在机器规模上实现了相同的分离。一个PRD文件定义带有验收标准的故事。每个故事会生成一个全新的代理，接收当前git状态和前序代理完成情况的简报。代理进行实现，一个独立的验证器运行测试（绝不信任代理的自我报告），三个代码审查者并行评估差异。整个编排通过bash脚本中的claude --print调用运行。无框架，无运行时，无服务器。

规划/执行分离在终端中有效，因为终端使这种分离成为结构性的。规划产出文件。执行消费文件。两个阶段之间的边界是磁盘上的文件，可见且可审计，而非隐藏在IDE插件内部的状态转换。

为什么CLI在代理场景中优于IDE

论证建立在三个支柱之上：成本、组合性和上下文效率。

成本：94%的Token减少

Kan Yilmaz在四个场景中测量了MCP与CLI的token开销。³数据说明了一切：

MCP将工具模式注入每一次对话。拥有84个工具时，仅模式开销就在代理执行任何工作之前消耗15,540个token。CLI调用不携带模式开销，因为模型已经理解标准命令行接口。¹⁰一位用户记录了MCP_DOCKER在135个工具上消耗125,964个token。¹⁴

Jannik Reinhard在一个Intune合规任务上运行了并行基准测试：通过MCP消耗145,000个token，而通过CLI仅需4,150个token即可获得等效输出。¹⁰CLI代理有95%的上下文窗口可用于推理。MCP代理将大部分预算花在了工具定义上。

组合性：Unix管道早已解决

Vercel的v0团队移除了代理80%的工具，用单一bash环境替代。⁹结果如下：

Andrew Qu解释了背后的逻辑：”我们在解决模型本身就能处理的问题。”文件系统、grep、管道和重定向本身就是可组合的。模型理解它们。为cat | grep | jq本身就能处理的操作构建自定义MCP工具，只会增加开销而不增加能力。¹³

Anthropic自身的文档也印证了这一模式。Claude Code遵循Unix哲学：将日志通过管道传入，在CI中运行，与其他工具链式组合。⁵无头模式（claude -p）支持结构化JSON输出、模式强制验证和通过捕获的会话ID恢复会话。Anthropic将无头模式定位为CI/CD和脚本化工作流的主要集成路径。⁵

Simon Willison点明了其含义：编写代码现在很廉价。⁶没人愿意听的推论是：验证现在才是昂贵的部分。CLI代理可与现有验证基础设施组合。测试运行器、代码检查器、类型检查器、安全扫描器、部署流水线——全都是命令行工具。IDE代理需要为每一个编写插件。CLI代理通过管道连接它们即可。

上下文效率：聚焦信号而非噪声的推理

上下文窗口是有限的。每一个花在工具模式、对话历史和MCP开销上的token，都是无法用于推理的token。CLI架构从设计上就保持上下文预算精简。

一次全新的claude --print调用接收一个聚焦的提示（约2K token），而非继承完整的对话上下文（约100K+token）。每次操作从干净状态开始。没有累积状态。没有过期的工具定义。没有对话漂移。

我的基础设施运行84个钩子，覆盖17个生命周期事件，全部通过CLI调用编排。每次代理生成都会获得一份简报：当前git状态、前序代理完成情况的摘要，以及该单一任务的验收标准。简报而非记忆。模型执行清晰简报的效果远优于在30步累积上下文中导航。

一篇关于代理系统中Unix哲学的学术分析将这一原则形式化：将多样的接口收敛为统一的抽象，以牺牲部分专业化换取组合性和可处理性。¹¹类文件抽象和基于代码的规范降低了认知和工程负担。CLI代理继承了50年的设计积累。

Remote Control改变了格局

对CLI优先代理最明显的反对意见是：您会失去IDE的可视反馈。Anthropic在2026年2月25日发布了答案。Remote Control通过任意浏览器或Claude移动应用连接到本地Claude Code会话。²该功能在Hacker News获得531点赞和313条评论。

Remote Control不会将任何内容迁移到云端。代理继续在本地运行。终端会话通过TLS向Anthropic的API注册并轮询任务。所有流量通过出站HTTPS传输。无需开放入站端口。²

该功能解决了监管缺口。在Remote Control之前，CLI代理只有两种模式：有人监管（守在终端前）或无人监管（离开后听天由命）。Remote Control创造了第三种模式：异步治理。审批提示路由到您的手机。您可以在任何地方批准、拒绝或重定向。

我的钩子系统按影响范围分类操作。本地操作（文件写入、测试运行）自动批准。共享操作（git提交）发出警告。外部操作（推送、部署）交由人工审核。Remote Control将”交由”路径从阻塞等待变为异步通知。代理继续处理下一个故事，而我从手机上审查前一个。

IDE变成了显示层，而非执行环境。您通过Remote Control监控进度。当质量门控标记问题时您介入。CLI代理执行工作。IDE向您展示结果。

Bash代理模式

Vercel的just-bash是一个带有内存虚拟文件系统的模拟bash环境，专为AI代理构建。⁴其设计编码了关于代理架构的三个信念：

隔离优于沙箱化。 每次调用在隔离环境中运行。环境变量、函数和工作目录在调用之间重置。文件系统持久化。延迟文件加载意味着文件在首次读取时加载并缓存，绝不加载代理写入后未读取的文件。代理无法在跨操作中污染自身环境。

复用现有工具而非自定义工具。 Grep已有50年历史，它所做的正是自定义搜索MCP工具所复制的。jq解析JSON。curl获取URL。模型从训练数据中了解这些接口。自定义工具需要注入模式和文档。标准工具两者都不需要。

最小化架构优于框架架构。 Andrew Qu捕捉到了这一原则：”模型越来越智能，上下文窗口越来越大，所以最好的代理架构可能几乎不需要架构。”¹³

我的工具链在生产规模上验证了这一模式。约15,000行bash编排Claude Code。84个钩子覆盖17种事件类型。调度器、质量门控、语义搜索集成、自主循环。无Python运行时，无框架依赖。Bash的粗糙之处（无原生JSON、无异步、无正式数据结构）确实存在但可解决。jq处理JSON。顺序处理实际上是一个特性：门控应该按顺序运行，而非竞态执行。

该模式之所以有效，是因为代理编排从根本上就是读取stdin、做出决策、写入stdout。这个描述与bash的设计目的完全吻合。任何更复杂的需求说明任务分解有问题，而非工具有问题。

成本作为架构决策

成本决策会产生复合效应。对无状态操作选择CLI而非MCP，每次调用节省94%。³以每天100次操作计算，仅工具定义开销每月就能节省$228。³这些节省释放出的预算可用于更多操作，从而产生更多节省。架构在为自身买单。

三个成本层独立产生复合效应：

Token层。 系统提示压缩。我通过一个CLAUDE.md文件和8个规则文件运行约3,500个token的系统提示。约束比解释更高效。”拒绝匹配敏感路径的工具调用”与15行关于为何应保护凭据的解释做着同样的工作。Anthropic的最佳实践文档强调了同一点：上下文窗口填满时性能会下降。⁷每个浪费的token都有双重成本：一次是直接的API费用，另一次是推理质量的退化。

代理层。 新鲜生成优于长对话。自主运行中的每个故事都获得一个拥有干净上下文窗口的新代理。Geoffrey Huntley记录了一个类似的模式，称为”The Ralph Loop”，在Sonnet上以每小时$10.42运行自主开发。¹²上下文永远不会膨胀，因为每个代理都从零开始。系统提示的缓存命中成本降低90%（Opus 4.6上$0.50 vs $5.00每百万token），因此跨新鲜生成重复的系统提示开销极小。⁸

架构层。 CLI用于无状态操作，MCP用于有状态操作。一次用于一次性评估的claude --print调用不增加连接开销。当工具需要持久状态或流式传输时，MCP更合理。大多数代理操作是一次性的评估、分类或代码生成任务。CLI以更低成本和更简单的调试处理所有这些。

上周我的自主循环中的一个具体案例：五个PRD故事在夜间处理完毕。¹⁵每个故事生成一个全新代理（约2K token简报），运行实现（平均约15K token），然后生成三个审查代理（每个约2K token）。每个故事总计：约23K token。同样的工作流在长时间运行的MCP对话中，到第三个故事时每个故事就会携带约100K+token的累积上下文。五个故事通过CLI：总计约115K token。五个故事通过MCP对话：总计500K+token。成本比率随每增加一个故事而复合增长。

MCP仍占优势的场景

CLI论点并非普遍反对MCP。在CLI力不能及的特定场景中，MCP更具优势。

有状态的工具服务器。 在跨调用间维护连接池的数据库浏览器从MCP的持久服务器模型中受益。每次CLI调用都重新连接会增加延迟和认证开销。如果工具在调用之间需要状态，MCP是正确的选择。

结构化验证。 MCP工具模式强制执行输入/输出契约。CLI调用接受任意文本。当代理必须提供匹配精确模式的结构化输入（API密钥格式、日期范围、枚举选项）时，MCP模式在工具处理之前就能捕获格式错误的输入。CLI验证需要工具本身或包装脚本来强制约束。

多租户访问控制。 MCP服务器可以集中强制执行每用户权限。CLI工具继承操作系统用户的权限。在不同代理需要不同访问级别的团队环境中，MCP提供更细粒度的授权。

流式响应。 产生增量输出的长时间运行操作（日志跟踪、构建进度、数据库导出）通过MCP的流式协议比通过阻塞直到完成的CLI调用效果更好。

决策规则：如果操作是无状态且一次性的，使用CLI。如果操作需要持久状态、结构化契约或流式传输，使用MCP。在我的工具链中，约90%的操作是无状态的。真正需要MCP的10%确实从中受益。优化这90%产生最大回报。

今天就可以构建的方案

三个模式，每个都可在一个下午内构建，且彼此复合增益。

模式1：规划/执行分离

# Plan phase: research and plan, no implementation
claude -p "Research the codebase and write research.md" \
  --allowedTools "Read,Glob,Grep,Write"

# Review: read annotations in research.md, write plan.md
claude -p "Read my annotations in research.md and write plan.md" \
  --allowedTools "Read,Write"

# Implement: follow the approved plan
claude -p "Implement the plan in plan.md" \
  --allowedTools "Read,Write,Edit,Bash"

每个阶段获得范围化的工具权限。规划代理不能编辑代码。实现代理不能浏览网页。文件边界强制执行分离。--allowedTools标志在CLI层面执行强制。无需配置文件。无需插件设置。每次调用一个标志，精确限定该阶段所需的权限。

标注循环是与”只是更好地提示”的关键区别。您在编辑器中审阅计划。您划掉不同意的部分。您在边距添加注释。代理读取您标注过的文件并修订。计划在每次传递中变得更好，因为两种不同的智能（人类领域知识、模型代码生成）汇聚在同一文档上。

模式2：每个任务全新生成

for story in $(jq -r '.stories[].id' prd.json); do
  # Each story gets fresh context with a focused briefing
  criteria=$(jq -r ".stories[] | select(.id==\"$story\")" prd.json)
  state=$(git diff --stat HEAD~1)
  briefing="Git state: $state --- Story: $criteria"

  claude -p "Implement: $briefing" \
    --output-format json \
    --allowedTools "Read,Write,Edit,Bash,Glob,Grep" \
    | jq -r '.result'

  # Independent verification: never trust self-report
  python -m pytest -v
done

无累积上下文。无对话漂移。每个代理获得一个干净窗口和聚焦的简报。--output-format json标志捕获包含会话ID的结构化输出，如果故事需要后续工作，可实现确定性的对话恢复。

独立验证步骤比实现步骤更重要。代理会表现出我所说的幻影验证：声称测试通过而未实际运行。在代理上下文窗口之外运行pytest完全消除了这种故障模式。代理无法虚报它从未产出的结果。

模式3：并行审查流水线

diff=$(git diff HEAD~1)

# Three reviewers with independent context
claude -p "Review for bugs: $diff" --output-format json > /tmp/correctness.json &
claude -p "Review for vulnerabilities: $diff" --output-format json > /tmp/security.json &
claude -p "Review for style issues: $diff" --output-format json > /tmp/conventions.json &
wait

# Merge findings from all three
jq -s 'map(.result)' /tmp/correctness.json /tmp/security.json /tmp/conventions.json

三个代理。三个视角。零共享状态。审查者之间的分歧恰好暴露出单一审查者遗漏的问题。&运算符和wait内建命令处理并行化。无需异步运行时。无需线程池。无需编排框架。Bash作业控制完成这项工作。

该模式的力量在于：每个审查者将完整的上下文窗口用于其唯一关注点。单一审查者在正确性、安全性和风格之间分散注意力，表现不如三个拥有专用上下文的专家。CLI使这种拆分变得轻而易举，因为每次调用都是一个拥有独立内存的独立进程。

关键要点

面向构建代理系统的开发者： - 所有代理生成从claude -p开始。仅在需要持久状态时才添加MCP。 - 按阶段划分工具权限。规划代理读取。实现代理写入。审查代理读取差异。 - 对无状态操作选择CLI而非MCP，token开销预算减少94%。³

面向扩展自主工作流的团队： - 全新代理生成防止上下文漂移，并将每次操作的token成本封顶。 - Remote Control将”无人监管”转变为”异步监管”，无需改变CLI架构。² - Vercel的数据证明了一个反直觉的结论：更少的工具意味着更高的成功率，而非更低。⁴

面向选择代理基础设施的架构师： - CLI代理可与现有CI/CD、测试和部署工具组合。无需集成工作。 - Unix哲学（通过管道组合小工具）早于且优于所有代理专用框架。¹¹ - 当您不再将代理视为聊天工具，而是开始将其视为基础设施时，10%生产力瓶颈才能被突破。

AI Engineering系列文章之一。另见：Claude Code作为基础设施、爪痕解剖、自主循环和10%瓶颈。