AI Agent 不是玩具，是工具人

我不太把 AI 当成陪聊对象，也不太在意它会不会给情绪价值。我对 AI 的期待一直很简单：

少说废话，直接把事做完。

AI Agent 工具人开发工作流

这篇写成一份检查清单：交给 Agent 之前问什么、它做完之后看什么、哪些事适合交给它。

检查 1：普通问答 AI 和 Agent 的区别

	普通问答 AI	Agent
给你什么	教程和建议："你需要创建文件、复制内容、运行命令……"	"我已经做了，验证结果如下"
能不能操作	不能，你自己动手	能看文件、改代码、跑命令

一句话：前者给答案，后者交付结果。 如果它已经有权限操作文件和终端，就应该直接创建、修改、运行、验证，而不是把步骤讲给我听。

检查 2：这件事值不值得交给 Agent

不是所有任务都适合自动化。我先看三个条件：

条件	要问的问题
输入清楚	文件、目标和限制条件能不能说清楚？
动作重复	这件事是不是有一套可以重复执行的步骤？
结果可验	能不能通过测试、日志、截图或实际打开来确认？

三个条件越齐，越适合直接交给 Agent。反过来，目标模糊、过程高度依赖判断、结果又无法验证时，先让它讨论方案，比让它假装完成更稳。

检查 3：它有没有形成验证闭环

一个不会验证的 Agent，很容易变成高级甩锅机：

它说"已修复"，但没看日志
它说"已发布"，但没确认 Git push 成功
它说"页面正常"，但没打开页面，也没看截图

这种 AI 看起来很勤快，实际会制造更多工作量，因为你还要替它验证。我判断一个 Agent 靠不靠谱，看它有没有这个闭环：

接任务 → 查现状 → 动手改 → 跑测试 / 构建 → 看结果 → 失败继续修 → 成功再汇报。

少了验证，前面做再多都不稳。关于这一点的完整复盘，见《没验证就汇报，是 AI 协作里最贵的坏习惯》。

检查 4：它能不能接到"现场"

真实工作都在本地：项目文件、.env 配置、博客仓库、WSL 或服务器上的日志、Git 状态、构建结果。如果 AI 看不到这些，它只能猜，而我最讨厌猜。

能读文件、跑命令、改代码、看日志，AI 才能从"建议者"变成"执行者"。这也是我折腾 Hermes、Telegram、WeChat bot、本地博客和自动化脚本的原因：不是为了酷，是为了把 AI 放进我真正做事的地方。

适合交给 Agent 的事

类型	具体例子
检查类	检查文章格式、扫描图片路径、跑构建
排查类	查为什么服务没回消息、根据日志定位问题
记录类	写 commit message、总结改动
交付类	推送仓库、生成封面草图

这些事不一定难，但烦。越烦的事越容易因为懒而跳过，比如验证、检查、整理、记录。Agent 的价值，就是把这些容易被人省掉的步骤补上，前提是你要求它补上，而不是允许它说一句"应该可以"。

我对 Agent 的几条固定要求

回复短一点
直接做
不要假装完成
出错说实话
commit message 写清楚
配置改完要重启验证
博客推送前要 build

如果这些每次都要重新说，AI 就还停留在一次性工具。真正适合长期使用的 Agent，应该有记忆、有习惯、有技能。这不是为了让 AI 更像人，是为了让它更像一个熟练工。

这篇的局限

这是我自己的工作方式。我写代码、管博客仓库、跑本地服务，对 Agent 的要求和只用 AI 做问答的人不同。
"Agent 能直接操作文件和终端"意味着风险：给权限之前，要想清楚它能改什么、能不能回滚。
文中提到的工具和做法会随产品变化。

一句话

AI Agent 的价值，不是更会聊天，而是更能把事情闭环。能查、能改、能跑、能验、能推，才是我愿意长期用的工具人。

AI Agent 不是玩具，是工具人 ​

检查 1：普通问答 AI 和 Agent 的区别 ​

检查 2：这件事值不值得交给 Agent ​

检查 3：它有没有形成验证闭环 ​

检查 4：它能不能接到"现场" ​

适合交给 Agent 的事 ​

我对 Agent 的几条固定要求 ​

这篇的局限 ​

一句话 ​

相关推荐

评论区