不要用 chat 思维去使用 agent
/research/do-not-use-agent-as-chat-tool.md
我观察朋友使用 agent 的方式之后，发现他是用 chat 的思维去使用 agent，于是写了这篇。对于经常用 agent 的人或许没有问题，但是对于新手我觉得这个误区是存在的。
两种思维
chat 思维指通过和 AI 聊天的方式来获取知识，解决自己的疑惑。agent 思维指让 agent 去完成一件事情。这两者的本质差别是人使用AI的目的是什么：学习就用 chat，做事就用 agent。新手容易习惯性的把 chat 思维带入在 agent 的使用中，这其实不是推荐的做法，因为在 agent 的使用中混入大量对细节的提问可能会让 agent 偏离任务目标，最终完成任务的效率变低。
agent 的用法
整体的思路是：告诉 agent 你的目标是什么，以及如何验收或评估可以确认为完成。这个目标可大可小，但为了让 agent 做的是符合自己预期的，就需要提供更多的细节：告诉 agent 自己能够确定的内容来约束它的行为，避免过度发散出来的方案不是自己想要的。agent 有了大的目标方向以及具体的要求就会自主去做规划，按照规划一步步去执行，最后验证每一步是否正确。而最开始写的的验收评估的标准决定着 agent 能否最终结束任务。如果所有计划都执行完了仍然达不到验收标准，agent 会自主去发现问题，重新进入 “规划-执行-验证” 的循环，直到验收完成。而在整个过程中用户观察 agent 的行为，如果有不符合自己预期的地方，随时可以干预，补充新的要求。
除非自己很清楚任务具体需要哪些步骤，不要自己去拆计划。当自己就清楚做完一件事情的一二三四步的时候，本质上是在将 agent 当苦力用：去做具体的执行。而如果自己不了解，自以为觉得 agent 需要做哪些步骤时，轻则选择的不是最优方案，重则陷入到无限的细节里面去，最后发现整体方向就是错的。把专业的事情交给专业的 agent 去做。大模型训练了那么多的知识，要相信它的规划比人靠谱得多。此时人应该退居二线，只做方向把控。
克制住学习的欲望，我们可以有更好的方式来学习。agent 执行中产生的大量中间内容用户看不懂是正常的，这时不要去追问这些细节。记住我们的第一目标是做完这件事情，而不是学习其中的各种知识概念。如果`一目标就是学习，那就不应该用 agent，只先用 chat 来把所有的疑惑都解决了，再让 agent 去做。但这样效率很低不是嘛？这和传统的手工部署已经没有许多差别了。agent 只是用来当苦力就太暴殄天物了，它真正的价值是探索寻求最优方案后执行复杂任务等。如果所有任务在开始前人要先学一遍，那就没有发挥 agent 真正的价值。
“不动脑子、不学习新知识，只是告诉 agent 我的目标和需要的效果是怎样的” 的思路对于简单任务或许奏效，但一旦任务复杂就会失控。你完全看不懂 agent 在做什么自然也给不出什么建议，agent 如果在方向上走偏离你也没有能力纠正，所以学习也很重要！事实上不同的人使用 agent 的效果天差地别就源于知识储备的差异。懂得更多的人能更好的掌控 agent 朝自己希望的方向运行，也更能问出有价值的、有深度的好问题。我在前面已经批评了在 agent 执行过程中去提问学习的方式，所以如何更好的使用 agent 去学习？
我的方法是在 agent 做完任务之后，让它写一篇复盘文章。可以让它写出整个折腾的流程和涉及的技术细节。用户如果对文章中概念不理解，可以继续追问，让 agent 不断去补充完善，直到彻底理解。这样的好处是可以系统性的学习，这比在 agent 执行中碎片化的学习要好。agent 刚执行完整个任务，上下文还是热乎的，更能够从整体的角度去介绍知识。这样我们即让 agent 完成了任务，又学到了知识。
具体的例子
以 “在云主机上部署 axonhub，用来中转 codex gpt5.5” 为例子，让我写提示词，我会这样写：“我需要在云主机上部署最新版的 axonhub 并将 API 暴露到公网使用。axonhub 中我会登录 codex，因此需要稳定的 VPN 环境。最终验收的标准是能够从公网使用 axonhub 提供的 codex 中转的 API 服务。补充：云主机的登录方式是：xxxx；已经有的 vless 的连接串是: xxxxx；”。
我觉得上面的提示词足以让 agent 完成这个任务了。把提示词拆解开就是我前面提到的那几个点：
- 目标：在云主机上部署最新版的 axonhub 并将 API 暴露到公网使用。
- 补充的约束：需要稳定的 VPN 环境。
- 提供 agent 执行需要的材料：云主机登录信息 和 vless 的连接串
- 验收的标准：能够从公网使用 axonhub 提供的 codex 中转的 API 服务。
理想情况下：
- agent 会根据云主机的登录信息登录上去。
- 根据提供的 vless 串去部署在当前主机环境下适合的代理客户端并把 vless 配置进去。
- 去 github 查看 axonhub 最新版本并部署到主机上。
- 查看暴露到公网的端口和反向代理软件等，它会推荐你使用主机上已经部署好的 caddy 来做反向代理。
- 配置好反向代理之后会要求你去云服务提供商后台添加一条二级域名的 DNS 解析。
- axonhub 这块它会先配置好前面 vless 的本地代理。
- 然后要求你登录 codex 或主动帮你触发登录验证，让用户使用提供的链接到浏览器登录后提供回调地址，这样 axonhub 就连上了 codex。
- 最后本地 curl 调用 axonhub 暴露的 api，确保服务正常。
- 等用户添加完二级域名解析后，就可以直接从公网使用了。
以上是 agent 可能会做的步骤，但不一定是按照这个顺序，因为 agent 会做统筹规划，可以并行做的事情就调用 subagent 去做。而 agent 没法做的事情比如添加 DNS 解析和登录 codex，就需要用户的介入。除此以外，在执行阶段我们不需要主动研究更多的细节。而如果你有一些个人的倾向，比如代理客户端选择哪个：v2ray, clash, sing-box 或其他，可以直接告诉它。如果不清楚选哪个，不要在过程中问哪个好，哪个不好的，直接说一句 “用最适合的客户端”，我觉得就够用。等任务完成了再让它系统的研究一下不同的客户的区别，不满意再换就是了。
如果达不到上面的理想情况，那就是模型或 agent 的能力不行了，这就需要更多人的介入，去帮 agent 做决定。