Agent 学习笔记：从会聊天到会行动#

1. Goal#

也就是目标。

目标越清楚，Agent 的行为越稳定。目标如果很模糊，比如“帮我弄好这个项目”，模型就容易不断试探、发散，最后做了很多动作，却不一定真的解决问题。

所以一个好的目标通常要尽量包含：

• 想完成什么
• 成功标准是什么
• 有哪些限制条件

例如：

1
帮我把 Astro 博客部署到 GitHub Pages，
2
要求使用 GitHub Actions 自动发布，
3
并确保访问路径适配 /ashenwitch。

这个目标就比“帮我部署博客”稳定很多。

2. Tools#

如果没有工具，Agent 再聪明也只能停留在纸上谈兵。

工具决定了它能不能真正接触外部世界，比如：

• 读写文件
• 执行命令
• 调用 API
• 搜索网页
• 读数据库
• 操作浏览器

我现在越来越觉得，很多所谓的 Agent 能力，本质上都是工具能力的外延。模型提供理解和决策，工具提供行动能力。

3. Memory / State#

Agent 必须知道自己现在处在什么阶段。

这里的“记忆”不一定非得是复杂的长期记忆系统，很多时候只要有一份可靠的状态记录就已经很有用了，比如：

• 当前目标是什么
• 已经执行了哪些步骤
• 上一次工具返回了什么结果
• 当前有哪些待办

如果没有状态，Agent 很容易重复劳动，或者在几轮之后忘了自己到底在干什么。

4. Planner#

不是所有 Agent 都一定要有显式的规划器，但“规划能力”几乎是必须的。

简单任务可以一步完成，复杂任务通常需要拆解。

比如“写一篇博客”看起来只有一句话，但实际过程可能是：

1. 确定主题
2. 列提纲
3. 写初稿
4. 润色结构
5. 补标题和摘要
6. 存入指定目录

如果没有规划，Agent 往往会在第一步就试图直接输出最终结果，质量会非常不稳定。

5. Executor#

规划不是结束，执行才是关键。

真正的难点往往出现在执行层，比如：

• 工具调用失败
• 文件路径不对
• 权限不够
• 返回结果格式和预期不同

所以 Agent 系统不能只会“想”，还得能处理现实里的不确定性。

它到底是不是“自主”？#

我现在的答案是：有限自主。

很多 Agent 看起来很主动，其实依然是在一个被约束好的框架里运行。它的“自主”，更像是在给定目标和工具集中的局部决策能力，而不是无限制自由发挥。

这个边界非常重要。

如果不加约束，自主性越强，翻车概率也越高。

Prompt 重要，还是 Workflow 重要？#

两者都重要，但在 Agent 场景里，我会越来越偏向认为 Workflow 更重要。

Prompt 决定单步质量，Workflow 决定整体稳定性。

一个提示词写得再好，如果流程没有重试、校验、回退、状态同步，系统还是会很脆。

评估为什么这么难？#

因为 Agent 不是只看最后一句回答对不对。

它的评估往往要看：

• 最终结果是否完成
• 花了多少步
• 是否走了弯路
• 是否错误调用工具
• 是否在失败后能恢复

也就是说，Agent 的评估更像评估“过程中的表现”，而不仅仅是“结果对错”。

1. 先做小闭环，再谈大而全#

比起一上来做“万能 Agent”，我更认同先把一个小场景跑通。

例如只做：

• 自动写日报
• 自动整理会议纪要
• 自动分析一个仓库并生成修改建议

这种小闭环一旦稳定，后面再扩展能力会更自然。

2. 工具返回结果一定要尽量结构化#

这一点非常现实。

如果工具返回的是一大段随意文本，模型每次都要重新理解，成本高而且容易误判。相反，如果返回的是结构化数据，比如 JSON、明确状态码、固定字段，Agent 的后续决策会稳很多。

3. 不要过度迷信“一次规划到底”#

复杂任务里的变化很多，一次性规划完整路径往往不现实。

我更喜欢“走一步，看一步，但每一步都知道为什么走”这种方式。也就是：

• 先有一个大方向
• 每轮只决定最合理的下一步
• 根据实际结果动态调整

4. 失败处理能力很重要#

很多系统演示都只展示成功路径，但真实环境里经常会遇到：

• 网络失败
• 接口超时
• 权限不足
• 文件不存在
• 格式不兼容

如果 Agent 无法识别并处理失败，那它的可用性会大打折扣。