如何正确使唤 Agent 及 错误案例

前言

几年前, 我写过一篇 如何正确提问及错误求助反面实例

最近, 世界来到了 AI 和 Agent 的时代, 我在各个群里看到了很多使唤 Agent 失败的案例. 有一些确实是 AI 和 Agent 能力不足, 但是还有很多是使唤方法不对.

我自己记录了很多 面向GPT开发, 面向Agent开发, 使唤Agent 的实际案例.

还写了 2 篇总结, 面向GPT开发总结 202601 和 面向Agent开发总结 202608

一方面是希望激发使用者转变为创造者 (就像我更早的时候记录自己古法编程的过程一样), 另一方面是希望展示一些成功使唤 Agent 的实例. 

就像, 看多了好的摄影作品, 自己拍照时也会自然地使用好的构图. 看多了成功的 Agent 沟通记录, 自己在和 Agent 交流时也会自然地使用好的表达方式.

实例 1

过程

A: Hermes 的模型提供商的名字能使用中文吗?

B: 可以啊.

A: 我跟 Hermes 讲了. 怎么不行?

B: 你讲了什么? TA 怎么反馈的? 有截图吗?

A 贴出与 Hermes 交流的截图, 略

B: 你的要求提得太笼统了. 你具体要改哪个提供商?

A: 就是群里面 XX 提供的, 我添加到 Hermes 了, 能正常使用, 但是我想改成中文名字方便识别.

B: 你向 Hermes 发 /model 命令, 得到什么

A 贴出截图, 略.

B: 你这么跟 Hermes 说

在 /model 命令返回的列表中, 有一项 cpa-xz, 把它修改为 cpa - 鞋总. 附图中红框指示的项.

A: 成功了!

分析

Hermes 的模型提供商, 分为系统预置 和 自定义添加.

自定义添加的模型提供商当然很容易修改名称, 但是系统预置的模型提供商改起来就比较麻烦.

当用户提出笼统的要求时, Hermes 以为要把全部的模型提供商的名称都改成中文, 改了好多文件, 有些是 Hermes 自己的程序文件.

实际上, 修改自定义添加的模型提供商的名称, 只要修改配置文件里面几行就够了.

小结

1. 对于自己不懂的领域, 向 Agent 提出的要求越详细越精确越好. 避免 Agent 错误地扩大范围.

懂的人会说 "我要把自己添加的模型提供商 YY 的名称改为 ZZ"

不懂你就老老实实说 "我在 XXX 场景下看到 YYY, 要修改为 ZZZ"

2. 描述一件 Agent 能看到的 / 感知到的事件或信息. 越具体越好.

在本案例中, /model 命令是刚刚发生的, Agent 很容易找到对应的日志.

在其它情况下, 你可以描述 "在 X 年 X 月 X 日 XX:XX:XX UTC+8, 你报错 YYYYYY, 请分析原因, 如何才能修复这个问题" 如果使用 Telegram 与 Agent 交流, 很容易找到消息的准确时间.

=========================

实例 2

过程

A 对 Agent: 部署 3x-ui 系统

系统部署成功了, 面板能登录, 能操作.

A 对 Agent: 在 3x-ui 系统中, 部署 vless, vmess, hy2, tuic 节点

Agent 说部署成功了. 但是 A 自测 vless, hy2, tuic 节点不通

B 对 Agent: 你自己配置客户端 对接服务端测试. 

Agent 报告测试成功.

B 对 Agent: 导出客户端对应的配置文件. 

B 在自己的环境上运行翻墙内核裸核 + 配置文件测试, 是通的.

B 问 A: 你用的什么客户端?

A 答: Karing

B 对 Agent: 你用最新版本的 karing 测试你的 3x-ui 的订阅链接. 看 4 个节点能否正常工作.

Agent 进行了一些操作, 发现订阅链接中的节点信息不是能正常工作的节点信息, 并进行了修复.
然后报告 vmess, hysteria2, tuic 通了, 但是 vless reality 不通. 原因是 Karing 内置 sing-box 1.13.19，它的 uTLS 不发 X25519MLKEM768 这个 key share，被 26.9.8+ 的 REALITY 门禁直接拒在认证之前
然后 Agent 把 3x-ui 的内核换成了 xray v26.7.28, vless reality 节点通了.

B 对 Agent: 你把 karing 测试通过的界面截图发出来.

Agent 发了截图, 界面显示是通的.

B 在自己的 karing 中测试, hy2 和 tuic 是不通的.

B 对 Agent: 提问, win 环境下 karing 的日志在哪里?

Agent 答: %APPDATA%\karing\karing\ 

B 对 Agent: 我在自己的 win 环境下 karing 中测试, hy2 和 tuic 是不通的. 附件是日志.

Agent 分析, 用户遇到的问题是 TLS 证书验证失败. 在搭建节点时 使用了自签证书. 在 Agent 自测时, 可以指定同样的证书. 而用户端要么指定同样的证书, 要么需要跳过证书验证.
接着, Agent 提到, 现在没有域名也可以给 IP 发正式证书了, 建议使用正式申请的 IP 证书.

B 对 Agent: 同意, 请申请 IP 证书, 更新你的节点设置.

Agent 自测 karing 4 个节点都成功.

B 测试 karing 订阅链接 4 个节点都成功.

A 测试 karing 订阅链接 4 个节点都成功. 

分析

这次搭建 3x-ui 系统和节点的实践中, 用户是没有自己的域名的. 所以, 和常见的 有域名的 搭建教程有区别.

Agent 按没有域名的条件, 选择了自签证书的方案, 设置了节点的参数, 使得 在用户自己的客户端 karing 测试时遇到了问题.

最终, 通过澄清用户的使用方式, 反馈用户客户端的报错日志, Agent 分析原因, 解决了问题.

小结

1. 向 Agent 说得越少, 最终结果越有可能不如你的意.

准确描述要求, "客户端使用 karing 输入 3x-ui 的订阅链接, 要能测试 vless, vmess, hy2, tuic 节点连通" 能缩小结果的范围.

2. Karing 是一个跨平台 APP. 在用户的环境和 Agent 的环境都能运行.

让 Agent 自己先进行测试, 节约人类测试的时间.

3. 向 Agent 提供日志.

软件记录的日志全面又准确, 比人类的描述和感觉更靠谱, 特别地, 这个人类啥也不懂 / 懂得不多.