日勿の部落格

摘要#

今天大家口中的“AI 编程”，其实常把三层东西混在一起说。最底层是 LLM 这样的基础模型，中间层是把模型放进“能看文件、能跑命令、能调用工具、能维护状态”的 Agent；最上层才是开发者真正天天接触的入口，例如 CLI、IDE 插件、GitHub 上的云端代理。

在 LLM 的语境里，广义的 Agent 不是“更大的模型”，而是以模型为决策核心、能规划、能调用工具、能维护上下文、能完成多步任务的软件系统。Coding Agent 则是广义 Agent 在软件工程领域的特化版本，它面向的是代码仓库、终端、测试、Git、Issue/PR、设计文档和第三方开发工具等环境。

从计算成本上也需要分开看。从技术上来说，这类系统都底层都在处理 token。但从商业上说，开发者显然未必总是按 token 原样付费。目前的计费方式包括：按输入/输出 token 计费、缓存 token 计费、隐藏 thinking token 计费、按 premium requests 计费，以及按“每 5 小时请求额度/每周请求额度/每月请求额度”订阅的混合模式。

LLM 如何走到 Coding Agent#

从技术起点看，现代 LLM 的底层仍然是“对 token 序列做条件生成”的模型。2017 年的 Transformer 论文奠定了注意力机制这条主线，GPT-3 则证明了大规模参数与数据扩展可以显著提升 few-shot 能力。因此今天的大多数编程助手，表面上像在“帮你写代码”，底层本质仍然是在做高维度的 token 预测与条件生成。

面向编程的能力随后沿着两条路线演进。第一条路线，是在代码数据上进一步训练的专用模型。第二条路线，则是把更通用的前沿模型做成“能处理开发任务”的系统能力：更长的上下文、更好地推理、更强的多模态能力、更强的工具调用能力。再往前一步，就是从“模型回答问题”进入“模型参与执行工作”。各家大模型厂商近两年的官方平台就是把这种模式产品化，如 Claude Code 和 Codex。

如果把 LLM 当作文字推理引擎，那么广义 Agent 就是让这个引擎在环境中持续做事的应用形态。OpenAI 的定义很直接：

Agent 是计划、调用工具、跨专家协作并保持足够状态以完成多步工作的应用程序。

Anthropic 的表述则更工程化：

Workflow 通过预定义代码路径把 LLM 与工具串起来，Agent 则允许 LLM 动态决定自己的过程与工具使用。

简单来说，智能体可以表述为“模型 + 工具 + 循环”，直到达到停止条件为止。这一区分非常关键，因为很多开发者口中的“Agent”其实并不是完全自治体，而是“带一点自主性的工作流”。比如：

• “读取报错日志 → 搜索项目文件 → 给出修复建议”的脚本：Workflow
• 一个会自己决定先读哪些文件、要不要运行测试、需不需要继续搜索网络资料、何时请求你批准写入代码的系统：Agent

因此，今天的 AI 编程能力已经不适合只按模型排行榜来理解。更准确的理解方式是：模型能力决定上限，Agent Loop 决定能否把上限转化成真实开发产出。同一个模型，放进不同的权限边界、不同的工具集和不同的上下文管理策略里，开发体验会差非常多。OpenAI 专门写了 Codex agent loop 的工程拆解，Anthropic 也在 Claude Code 最佳实践里强调“先探索、再计划、再编码”。这说明行业竞争的重点，已经部分从“谁更会回答”转向“谁更会工作”。换言之，Coding Agent 与广义 Agent 的关系，本质上是“子集”关系。Coding Agent 是把广义 Agent 的规划、工具调用、状态管理和多步执行，放进了软件工程环境里：代码库、文件系统、终端、测试框架、lint、版本控制、Issue/PR、设计文档、MCP 工具、CI/CD 等，都是它的“世界”。

但是，也需要明确指出，Agent 的核心收益主要来自上下文管理、专业分工和并行化，但代价通常是更多 model calls、更高的 token 消耗与更复杂的调度。

为什么是 CLI#

CLI（Command Line Interface，命令行界面）是一种通过文字命令与计算机操作系统或软件进行交互的界面，通俗的理解就是俗称的“终端”。为什么现有的顶级 Agent 都会采取这种形式？原因很简单，应用程序随着框架的变化，架构设计是会改变的。而操作系统的接口无论如何都是不会变的，至少不会短期内剧烈变化。

举个简单的例子，早期的 AI IDE 大多基于 vscode，采用插件的形式进行辅助编码。但结果呢？受限于 vscode 自身的限制，文件的读取、写入、搜索都需要 vscode 提供底层支持才能进行。而 cursor 的横空出世告诉人们：可以 All in AI。CLI Coding Agent 就是秉持这一观念，你可以通过对话命令 CLI 调用系统接口，例如 Windows 的 Powershell 或是 Linux 下的 Bash，来实现任意的文件操作，进而进行编码。相对应的，也可以命令 Agent 执行指令。于是你会发现，“编码 + 指令”，已经构成了完整的 develop 过程。

复杂的 Token 计费模式#

天下熙熙皆为利来，天下攘攘皆为利往。互联网企业在 21 世纪已经对产品推广模型形成了一种路径依赖，这也是各位能够免费使用 GPT、Gemini、Qwen、豆包等模型的原因。

从技术定义上说，token 是模型内部处理信息的最小单位之一，它可能是一个单词、一个字符，甚至是字节/Unicode 级别的片段（例如图片、音频）。对于模型接口，上下文窗口、输出上限、缓存命中、并行工具调用成本，最后都会落在 token 上。而 tokenization 指的就是把原始文本切成 token 的过程，针对这一过程，各大厂商使用的 tokenizer 当然不同。因此，不同 tokenizer 会影响词表大小、效率和 OOV 处理方式。

从计费模式上说，在 API 世界里，只需以输入 token 与输出 token 为基本计费单位，然后叠加缓存、批处理、工具和长上下文的差异化收费，通过简单地相乘再相加即可得到资费详情。但除此之外，还有两类“看不见但会付钱”的 token。第一类是工具开销：在 Anthropic 文档里，tools 参数、tool_use、tool_result，乃至自动插入的 tool-use system prompt，都会进入 token 计费。第二类是思考或推理开销：Gemini 定价页直接把输出价格标注为 “including thinking tokens”；Anthropic 也写明即使你最后只看到了被总结后的内容，extended thinking 也是按完整 thinking tokens 计费的。这意味着，对于 Agent 来说，“让模型多想一步”往往确实能提升质量，但它并不免费。

而在 LLM API 之外，，一个令人头疼的现状是，计费和 token 的关系不再是一条直线。在计费方式上，由于 token 的开销急剧增长，计费和 token 直接划等号的计算方式似乎有点令人难以接受。于是，秉持着太阳底下没有新鲜事的原则，各大厂商火速推出了自家的 Coding Plan。通常来说，是按照“每 5 小时、每周、每月”的请求额度管理。具体到各个厂商，有的是背后是按照消耗的 tokens 进行统计，有的是按照请求数进行统计。例如单次提问会按实际模型调用次数扣额度，简单任务大约消耗 5–10 次，复杂任务可能 10–30+ 次等。这意味着，哪怕你 prompt 很短，只要 Agent 在底层反复读文件、调工具、重试验证，额度照样会快速下降。

这种计费方式的转变直接带来几个问题。首先是资源消耗不再透明，从用户端很难控制模型的请求次数，绝大多数操作都由 Agent 接管，在 LLM 引导 Agent 犯傻时，甚至会空跑额度去做大量无意义的工作。其次是，当即用即停的权力被“套餐”被包裹时，购买 Coding Plan 的决策很难说是一种便宜还是一个陷阱。就现状而言，各大厂商的 Coding Plan 或类似产品朝令夕改、霸王条款已经屡见不鲜。尤其是某些地方决策层莫名其妙地联合企业推行龙虾这种东西，导致国产算力不足的缺陷被进一步放大。一键式部署龙虾意味着一大批人将轻松的挤兑甚至挥霍本就捉襟见肘的算力，进而引发厂商的极端化应急处理，比如粗旷的封杀账号。

当然，从商业角度看，Coding Plan 必然是赔本赚吆喝的前期战略举措，而也有企业反其道而行之，不愿意随大流。小米推出的 Token Plan 在 Coding Plan 的基础上，不做花里胡哨的限制，直接按照 tokens 数量进行套餐售卖。但代价就是该套餐属于盈利性产品，因此价格相比其他厂家套餐会极其昂贵（因为其他厂家真的是在亏本卖）。