很多 coding agent 的讨论都是关于“它会不会按要求生成代码”，当模型写代码的能力趋于同质化时，coding agent 的上限往往不由大模型的生成能力单方面决定，而是由系统的过程控制、边界划分与协作协议决定的。模型会写代码当然重要，但当任务变成多步骤、要调用工具、可能碰到风险操作、还得把过程讲清楚给人看时，差距就不再只是模型能力的差距，而是系统设计的差距。

过程重于生成

最近我在拆 kimi-cli 的过程中找到了一个具象的切入点：表面上它是一个命令行工具，里面其实更像一个小型协作系统。你在命令行里输入一句任务，表面看只是“回车，然后开始跑”。但从系统内部看，事情没那么简单：界面要持续更新，Agent 要一步一步推进，工具调用要在合适的时机触发，有些操作还会停下来等你确认。用户看到的是一条输出流，系统处理的却是另一回事——它在同时处理节奏、状态、边界和人机协作。也正因为这样，很多 coding agent 的差距，看起来像“好不好用”的差距，本质上其实是“过程设计得好不好”的差距。

我想把 kimi-cli 当成一个样本，借它回答一个更有长期价值的问题：拆一个 coding agent到底该先看什么，才能看出亮点、边界和可借鉴的地方？我的第一版观察地图会先放在四个层面：它怎么“跑起来”、怎么“控风险”、怎么“跟人协作”、以及怎么“长期演进”。后面的连载也会沿着这四条线往下拆——不追求把源码讲完，只追求把设计取舍讲清楚。

第一层：它怎么“跑起来”

很多人会把 coding agent 想成“模型回复一次 -> 调工具一次 -> 输出结果”，像一个稍微聪明一点的脚本。但真实一点的场景很快会把这种想象打碎：一个任务可能要先读文件、再搜目录、再改代码、再跑命令、再看报错、再回退、再重试。也就是说，它不是在回答一个问题，而是在推进一个过程。kimi-cli 给我的第一个信号就是，它内部把这件事当成了“循环推进”的系统问题来处理，而不是“单轮对话”的包装问题。你会看到类似 run_soul()、_agent_loop()、_step() 这样的结构线索——这不只是代码组织方式，它反映的是kimi cli设计者对任务本质的判断：coding agent 的核心不是“会说”而是“能推进”。与其投入巨大精力让模型在一步内做对所有事，不如设计一个鲁棒的循环机制，让模型有空间“犯错并自我修正”。

第二层是它怎么“控风险”

Agent风险控制往往被很粗糙地对待：要么“全部自动执行”，追求爽感；要么“每一步都确认”，追求安全感。真正难的恰恰是中间地带：哪些操作应该无感通过，哪些操作必须提醒，哪些确认可以在一个会话里批量放行，哪些必须一条一条过。这里的设计不是“弹窗细节”，而是产品立场。因为你一旦允许模型触达工具、命令和文件系统，风险就不再抽象，它会直接变成用户信任问题。kimi-cli 里与审批相关的处理（包括确认、拒绝、会话级放行这样的中间态）让我很有兴趣，原因不在于“它做了确认”，而在于它承认了一件事：效率和边界不是二选一，它们需要被设计成一个连续的、可调的机制（这一点我后面会另起文章单独拆）。

第三层是它怎么“跟人协作”。

跟人协作我觉得是被很多 agent 产品低估的地方。我们常常把 UI/TUI 当成“皮肤”，但对 coding agent 来说，UI 其实是系统能力的一部分。因为用户并不只需要结果，还需要对过程有最低限度的理解：它现在在干嘛、为什么停下来了、下一步要我做什么、刚才那一步到底改了什么。kimi-cli 的一些设计让我意识到，它不是简单把内部日志打印出来，而是在认真处理“系统内部发生了什么”与“人应该看到什么”之间的翻译问题。像 Wire 这样的消息通道设计（包括更原始的流与更适合展示的流）背后反映的是一种很务实的判断：如果系统不能把过程表达清楚，人就很难持续信任它。很多我们以为的“UI 不聪明”，最后追到根上，其实是协作协议没设计好，这不是美观问题，而是预期管理。

第四层是它怎么“长期演进”。

agent 一旦开始长功能，复杂度会涨得很快：模型提供商会变，工具会增，配置会分层，交互入口会从 CLI 扩到 Web，用户对行为边界的预期也会分化。这个时候，一个项目值不值得学习，不只看它当前能不能用，还要看它有没有给未来留空间。kimi-cli 在抽象层、配置与扩展路径上的一些安排（比如模型抽象、Agent Spec、工具接入路径，以及面向 Web UI 的会话进程处理思路）给我的感觉是：它不只是想做一个“能跑的命令行助手”，而是在尝试把“agent 作为系统”这件事认真落地。未必每个选择都适合所有团队，但这种“为演进留接口”的意识，本身就值得看。

kimi-cli 拆解的思考

我想写kimi cli拆解的系列文章，不是因为我想证明某个项目“领先”，也不是因为我想做一套面向源码的讲解课，而是因为我越来越觉得：对于程序员而言，讨论 coding agent如果只停在“效果展示”和“功能截图”，很容易错过真正有复用价值的东西。我们真正能学走的，往往不是某个 prompt，也不是某个 skill 技巧，而是它如何处理过程、如何划边界、如何组织协作、如何为未来留余地。这些东西不够“爽”，但它们才决定一个 agent 能不能从 demo 长成工具，从工具长成系统。

为了达成我的目标，我给自己提了如下要求：

• 不评价模型能力高低，重点放在过程与系统设计；
• 不把看到的设计都当成最佳实践，更关心它在什么场景里成立、在什么场景里可能代价过高；
• 提炼可迁移原则：如果你也在做 coding agent、AI 工具、或者任何“模型 + 工具 + 人协作”的系统，哪些取舍值得借鉴，哪些要谨慎照搬（如果你只是想做一个查天气的单步助手，强行引入复杂的 Agent Loop 和审批流，只会徒增维护成本）。

接下来的kimi-cli系列文章我会沿着四条线往下拆：

• Agent 循环机制：任务推进、步骤拆分与错误回退（How it runs）
• 工具系统与审批流：风险分级与会话授权（How it controls boundaries）
• 消息通道设计：内部事件流与外部展示流的分离翻译（How it talks to humans）
• 抽象层与扩展性：面向未来的插件化思路（How it evolves）

我拆 kimi-cli 不是为了梳理清楚源码，而是想借它这面镜子，把 coding agent 的过程设计看清楚一点。模型的的光芒常常盖住了Agent在背后的支撑，对于 Builder 而言真正值得学的往往是后者。

如果反馈不错，我再往后和其他项目做一些轻量的“设计立场”对比——不是比谁更强，而是比谁在为哪类问题买单。

坑挖好～～敬请期待后续系列文章

最后，附上kimi-cli的项目整体架构示意图：

graph TD subgraph L1 [第一层：CLI 入口] CLI["Typer CLI
cli/__init__.py"] end subgraph L2 [第二层：应用工厂] App["KimiCLI
app.py"] end subgraph L3 [第三层：Soul 核心] Soul["KimiSoul
soul/kimisoul.py"] end subgraph L4 [第四层：Wire 通信] WireLayer["Wire SPMC
wire/__init__.py"] end subgraph L5 [第五层：UI 前端] Shell["Shell TUI"] Print["Print"] ACP["ACP"] WireJSON["Wire Server"] end subgraph L6 [第六层：基础设施] KosongPkg["Kosong LLM"] KaosPkg["PyKAOS OS"] end L1 --> L2 L2 --> L3 L3 --> L4 L4 --> L5 L3 --> L6