刚用 Claude Code 的时候, 我花了不少时间纠结一个问题: 它到底是 agent 还是 assistant?

看了不少文章, 大部分试图给这两个词划一条清晰的线——assistant 一次一步, agent 自主完成目标。但实际用下来的感受是, 大多数工具两种模式都能切, 分界线没那么分明。

真正有意义的区别不是产品叫什么, 而是谁发起、谁控制、在哪里跑。

Assistant 模式: 你每步都要盯着

用 Claude Code 最基础的用法就是这样: 你打一句 prompt, 它动一下, 你看一眼, 然后你打下一句。

你在每一轮都掌握控制权。你决定下一步做什么, agent 只是执行。这种模式下:

• 你全程在场, 不太会出大问题
• 但你的注意力被绑死了——它动一下你就要看一下
• 适合探索性的工作: 调试、原型、架构讨论

Agent 模式: 定好目标就放手

把目标扔给 Claude, 它自己去读代码、改代码、跑测试, 最终给你一个结果。

这时候你的角色变了——你不再是驾驶员, 而是定目标的人和审结果的人。中间的过程你不需要每步都看。

这种模式下:

• 你的注意力可以解放出来, 同时干别的事
• 但风险也高了——它可能走偏了等你回来才发现
• 适合有清晰完成标准的任务: 重构、迁移、批量修测试

最实用的分法: 看触发方式

抛开理论, 实际工作中最好用的区分方式其实是谁触发的:

• 你在终端里敲命令 → Assistant 模式
• 定时任务跑起来的、GitHub Webhook 触发的、CI 里自动执行的 → Agent 模式

我自己最有价值的体会是: 不用纠结它该叫 agent 还是 assistant, 而是建立一条 pipeline——用 assistant 模式试出一个可靠的工作流, 然后把它变成定时跑的 agent 任务。

什么时候用哪种

我的判断法则很简单: 这个任务我需不需要在过程中做决策?

• 需要频繁决策 → 用 assistant 模式, 人在回路里
• 目标清晰, 执行过程是机械的 → 用 agent 模式, 放手让它干

实际干起活来, 大部分任务在两种模式之间来回切换。白天 assistant 模式做原型, 晚上让 agent 模式跑批量迁移, 第二天早上来看结果, 是很常见的工作流。

文章链接：