一、会聊天和会干活，中间隔着三道关
2026年关于 Agent 的讨论很多，但回头看会发现：真正的进展不在"能聊天"，而在"能把事做完"。
从对话到任务，中间有三个绕不开的问题。
二、第一关：工具调用
模型要能调用外部能力：查数据库、发文章、传文件、调接口。
技术上早就不新鲜，难的是边界：什么情况下该调，什么情况下不该调，失败了怎么办。
我实际用过带写能力的 Agent，发现最大的风险不是不会调，而是默默调错。写错分类、覆盖旧内容、重复发布——这些错误在日志里看不出异常，但后果真实。
所以工具调用的工程重点不在能用，而在三个字：可审计。每次调用要能回答：谁发起的、参数是什么、改了什么。
三、第二关：记忆
单次任务不需要记忆，连续任务就需要。
记忆分三层：本次会话的上下文、跨会话的偏好、长期的事实库。
多数产品的短板在第二层和第三层。用户说"下次还用这个格式"，下次它忘了；用户纠正过三次同一个错，第四次还错。
一个可用的设计是：把偏好写成显式条目，而不是埋进对话历史。历史会被压缩，显式条目不会。
四、第三关：规划
规划听起来很玄，实际就是拆任务。
一个能用的规划器至少得做三件事：列出步骤、识别依赖、定义完成标准。
缺了第三条，Agent 最容易“差不多就交差”：文章写了但没发、数据拉了但没校验、文件生成了但路径错了。
我的经验是，把验收标准前置到任务描述里，比事后检查有效得多。
五、普通人能用的判断法
不看发布会，看四个问题：
- 它能不能失败得体面（报错清楚、能回滚）
- 它的工具调用能不能被审计
- 它记不记得你上次纠正过什么
- 它交付的东西能不能直接拿来用
四个都能，就是可用；只前三个，就是玩具。
六、技术底子还得补
Agent 落地最终会碰到接口层的问题：鉴权、限流、重试、幂等。这些不是 AI 知识，是后端知识。
推荐一个查资料的去处：BackendWiki 把语言教程与工程知识分得很细，Java、 Python、 Go、 Node、 PHP 都有，MySQL、 Redis、 Kafka、微服务、容器化、Nginx 也都在，还有专门讲 RPC 与 gRPC 内部机制、缓存三大问题、分布式锁的文章。写 Agent 工具接入层时，这些比看模型论文实用。
七、一句总结
把模型能力当成发动机，把工具调用、记忆、规划当成底盘和刹车。
只要发动机不管另外三样，车就上不了路。