别只会用 ChatGPT：这 10 篇文章，基本讲清了 AI Agent 是怎么一步步发展起来的

这两年，AI 圈冒出了越来越多的新词：

Agent、AI Agent、Skills、Function Calling、MCP、AI Coding、Harness Engineering、Loop……

对于天天关注 AI 的开发者来说，这些词可能已经不陌生。

但对于产品经理、人力、运营、市场，以及大量只是把 AI 当作办公工具使用的职场人来说，很容易产生一种感觉：

怎么前两年还在学“提示词怎么写”，现在突然就开始讨论“智能体怎么自己干活”了？

其实，今天我们看到的 AI Agent，并不是某一天突然出现的新技术。

过去几年里，学术界和 OpenAI、Anthropic、Google、微软、Princeton、UC Berkeley 等机构一直在研究同一个问题：

怎么让大模型从一个“回答问题的聊天机器人”，变成一个真正能够完成任务的系统？

围绕这个问题，陆续出现了一批非常重要的论文和技术文章。

如果把这些文章按照时间顺序串起来，你会发现：

它们其实共同讲述了一件事——AI 是怎么从“会说话”，一步步走向“会干活”的。

今天不讲复杂公式，我们就用普通职场人能听懂的方式，看看其中最值得了解的 10 篇。

一、第一阶段：先搞明白，AI Agent 到底是什么

1.《LLM Powered Autonomous Agents》

这篇文章可以理解成：

AI Agent 的“入门总纲”。

以前我们使用 ChatGPT，通常是：

你问一句，它回答一句。

但真正的 Agent 不是这样。

一个能够独立完成任务的 AI，至少需要几种能力：

会思考、会规划、会记东西，还得会使用工具。

比如你跟 AI 说：

“帮我分析最近一个月公司的招聘情况，并给出招聘优化建议。”

真正的 Agent 不能只是凭模型已有知识给你写一篇文章。

它可能需要：

先理解任务→ 拆分任务→ 查招聘数据→ 调用 Excel 或数据库→ 分析结果→ 发现异常→ 再进一步分析→ 最后形成报告。

这篇文章最大的价值，就是把这些能力系统地归纳成了几个核心模块：

LLM、规划、记忆、工具使用。

今天我们设计的大量 AI Agent，基本还没有离开这个框架。

对于开发人员，它告诉你 Agent 系统应该怎么搭。

对于产品经理，它告诉你设计 Agent 产品时到底要考虑哪些能力。

对于普通职场人，它帮助你理解：

Agent 并不是“更聪明的 ChatGPT”，而是一套围绕大模型建立起来的任务执行系统。

二、第二阶段：AI 不仅要思考，还要一边干、一边看结果

2.《ReAct: Synergizing Reasoning and Acting in Language Models》

ReAct 是 Agent 发展过程中非常重要的一个概念。

它解决的问题其实特别容易理解。

如果一个人只坐在办公室里想，却从来不出去验证，很容易想错。

AI 也一样。

大模型如果只是一直“推理”，非常容易产生幻觉。

于是 ReAct 提出了一个非常经典的循环：

思考 → 行动 → 观察结果 → 再思考。

比如让 AI：

“帮我查一下这家公司值不值得去。”

它不是直接生成答案，而可能：

先判断需要哪些信息→ 搜索公司资料→ 查看公开经营信息→ 分析招聘情况→ 根据新信息调整判断→ 再继续搜索。

你会发现，这已经非常接近一个真正的人在工作的方式。

所以今天很多 AI Agent，本质上都在做类似的循环。

对普通职场人来说，ReAct 最重要的启发是：

不要只让 AI“想”，还应该让 AI 接触真实数据和真实环境。

三、第三阶段：别一上来就做超级 Agent

3.《Building Effective Agents》

这是 Anthropic 发布的一篇非常值得企业和职场人阅读的文章。

它提出了一个特别重要的观点：

不是所有事情都需要 Agent。

现在很多公司一做 AI，就想：

“我们是不是应该做一个全自动 Agent？”

但 Anthropic 的建议恰恰相反：

能用简单工作流解决的问题，就不要急着上复杂 Agent。

比如一个招聘场景：

简历上传→ AI 提取信息→ 根据岗位要求匹配→ 输出候选人摘要。

这种流程本来就比较固定。

完全可以使用一个稳定的 Workflow。

没必要让 AI 每次都自己决定“下一步做什么”。

只有遇到高度不确定的任务，比如：

“研究未来半年我们应该招聘哪些 AI 岗位，并制定人才策略。”

这种任务路径本身不确定，才更适合使用 Agent。

这篇文章还总结了几种非常实用的 AI 工作方式：

提示链、路由、并行处理、多个 Agent 分工，以及“一个负责生成、另一个负责检查”。

如果你正在公司推动 AI 落地，这篇文章非常值得看。

因为它实际上是在提醒大家：

AI 工程不是越复杂越高级，而是应该选择最稳定、成本最低、最适合业务的方案。

四、AI 想真正工作，就必须学会使用工具

前面解决的是“怎么思考”。

接下来还有一个更现实的问题：

AI 怎么干活？

于是就进入了 Tools 和 Skills 的阶段。

4.《Gorilla: Large Language Model Connected with Massive APIs》

Gorilla 研究的是一个非常现实的问题：

如果世界上有成千上万个 API，AI 怎么知道什么时候应该调用哪个？

举个简单例子。

你让 AI：

“查一下北京今天的天气。”

AI 自己并不知道实时天气。

它必须调用天气服务。

如果再说：

“查完天气，帮我订机票，然后把行程写进日历。”

这时候 AI 可能需要连续调用：

天气 API机票 API地图 API日历 API。

问题马上来了：

调用哪个接口？

参数怎么填？

接口变了怎么办？

如果 AI 自己编一个不存在的 API 怎么办？

Gorilla 就是在研究：

怎么让大模型更加可靠地使用大量外部工具。

这也是今天 Function Calling、Tool Use、Skills 等能力的重要技术基础之一。

对于普通职场人来说，可以把 Skills 理解成：

给 AI 配备不同的“工作技能”。

比如：

Excel 是一个技能。

搜索网页是一个技能。

查数据库是一个技能。

操作 CRM 是一个技能。

发送邮件也是一个技能。

AI 本身负责判断和协调，Skills 负责真正执行动作。

5.《HuggingGPT: Solving AI Tasks with ChatGPT and its Friends in Hugging Face》

这篇文章又往前走了一步。

它提出：

为什么一定要让一个大模型什么都会？

完全可以让一个 AI 当“项目经理”，再去调度其他专业模型。

比如用户说：

“帮我把这张照片里的人物识别出来，生成介绍，再做成一条短视频。”

一个模型可能负责理解任务。

一个模型负责图片识别。

一个模型负责生成图片。

一个模型负责语音。

另一个模型负责视频。

最后由大模型负责统一协调。

你可以把这种模式理解为：

一个 AI 主管 + 一群 AI 专家。

今天我们谈到的“多智能体协作”，背后的思想其实非常类似。

这对于企业组织也很有启发。

未来企业里的 AI，不一定是一个“万能机器人”。

更可能是：

招聘 Agent财务 Agent数据分析 Agent销售 Agent客服 Agent内容 Agent……

再由更高层的 Agent 统一协调。

五、为什么最近所有人突然都在讨论 MCP？

6.《Model Context Protocol Architecture & Specification》

如果说前面的工具调用解决的是：

“AI 怎么使用工具？”

那么 MCP 想解决的问题就是：

这么多 AI、这么多工具，能不能使用一种统一的连接方式？

以前做 AI 系统，经常出现这种情况：

ChatGPT 要接数据库，开发一次。

Claude 要接数据库，又开发一次。

公司内部 Agent 要接数据库，还得再开发。

如果还有 GitHub、Slack、CRM、文件系统、知识库……

接口会越来越多。

MCP 想做的事情，其实很像给 AI 世界设计一个“统一插口”。

以后 AI 应用按照统一标准，就可以连接：

文件数据库开发工具企业系统各种外部服务。

所以很多人会把 MCP 类比成：

AI 时代的 USB-C。

这个比喻虽然不完全严谨，但非常容易理解。

它真正重要的地方，不是又多了一个技术名词。

而是意味着：

AI 与企业数据、软件和工具之间的连接，正在逐渐标准化。

对于企业开发人员，这是一项非常值得关注的基础设施技术。

对于 HR、运营、财务等业务人员，你只需要理解一件事情：

未来 AI 能做多少事情，很大程度上取决于：

它被允许连接哪些系统和数据。

六、AI Coding 为什么突然进步这么快？

接下来的两篇文章，对程序员尤其重要。

但其实非开发人员也值得了解。

因为它们解释了一个非常关键的问题：

为什么换一个环境，同一个 AI 的工作能力可能差很多？

7.《SWE-bench: Can Language Models Resolve Real-World GitHub Issues?》

以前评估 AI 写代码，通常给它一道编程题。

比如：

“写一个排序函数。”

但真实开发根本不是这样。

一个程序员修 Bug，可能需要：

看几十个文件理解项目结构找到问题代码分析上下游依赖修改多个文件运行测试发现报错继续修改。

所以 SWE-bench 提出了一个更真实的测试方式：

直接让 AI 去解决真实 GitHub 项目里的真实问题。

这件事意义很大。

因为从这时候开始，大家逐渐发现：

评价 AI Coding，不能只看：

“代码写得像不像。”

而应该看：

这个问题最后到底有没有被解决。

这跟我们评价一个员工其实非常像。

不是看他说得多专业。

而是看：

最终有没有把事情做成。

8.《SWE-agent: Agent-Computer Interfaces for Software Engineering》

SWE-agent 又发现了一个特别重要的问题：

AI 干活好不好，不只是模型本身决定的。

你给它什么样的工作环境，同样非常重要。

比如让一个新员工入职。

如果你什么工具都不给他，资料也没有，系统权限也没有，然后让他自己想办法工作。

再优秀的人效率也不会高。

AI 也是一样。

如果给 AI：

好用的代码搜索工具清晰的文件结构方便编辑代码的工具及时的报错信息自动测试环境……

AI 完成任务的成功率会明显提升。

这个思想后来逐渐发展成今天非常热门的一个方向：

Harness Engineering。

中文可以理解成：

给 AI 搭建一套真正适合它工作的“工作环境”。

所以未来 AI 应用竞争，可能不仅仅是谁的大模型更强。

还包括：

谁给 AI 配的工具更好。

谁提供的上下文更准确。

谁的工作流程设计得更合理。

谁的反馈机制更完善。

这也是为什么现在的 AI Coding 产品越来越不像一个“聊天框”，而越来越像一套完整的开发工作台。

七、AI 怎么学会自己发现错误？

最后一个重要方向叫：

Loop，也就是循环。

简单来说：

以前的 AI 是“一次生成”。

未来的 AI 更重要的是：

生成 → 检查 → 修改 → 再检查。

9.《Reflexion: Language Agents with Verbal Reinforcement Learning》

Reflexion 研究的是：

AI 能不能自己总结失败经验？

比如一个 AI 做任务失败了。

传统做法可能是重新生成一次。

但 Reflexion 会让 AI进一步思考：

刚才为什么失败？

哪一步判断错了？

下一次应该避免什么？

然后把这些“经验”保存下来。

下一轮再尝试的时候，再读一下之前的失败总结。

是不是很像人在工作中的：

复盘。

比如一个销售第一次拜访客户失败了。

回来之后复盘：

客户真正关心的是价格。

自己介绍产品时间太长。

没有提前了解客户业务。

下一次再去，就会调整策略。

Reflexion 想让 AI 也具备类似能力。

这意味着 AI 开始从：

“做任务”

走向：

“做任务 + 复盘 + 改进”。

10.《Tree of Thoughts: Deliberate Problem Solving with Large Language Models》

最后一篇叫 Tree of Thoughts，也就是“思维树”。

普通大模型回答问题，经常是一条路走到底。

想到什么就继续往下生成。

但真正解决复杂问题的人通常不是这样。

比如做一个商业决策，你可能会同时考虑：

方案 A。

方案 B。

方案 C。

然后评估每个方案。

发现方案 A 有问题，就退回来。

再尝试方案 B。

Tree of Thoughts 做的事情，就是：

让 AI 同时探索多个思考方向，并且能够判断、选择甚至回退。

这特别适合：

复杂规划数学推理策略分析方案设计复杂决策。

它代表的是 AI 推理的一种变化：

以前更像：

想到哪写到哪。

未来则更接近：

先探索几个方案，再选一个更好的继续走。

把这 10 篇文章连起来，你会看到一条非常清楚的路线

如果把这些研究放在一起，其实可以把过去几年的 AI 工程发展概括成几个阶段。

最开始，我们研究：

怎么跟 AI 说话。

于是出现了 Prompt Engineering。

接下来开始研究：

AI 应该怎么完成一个任务。

于是有了 Agent。

然后发现 Agent 光会思考还不够。

于是开始研究：

怎么让 AI 使用工具。

于是有了 Tool Use、Function Calling 和 Skills。

工具越来越多以后，又出现一个问题：

AI 怎么统一连接这些工具？

于是 MCP 开始受到关注。

再后来大家又发现：

模型能力再强，如果不给它一个好的工作环境，也很难完成复杂任务。

于是出现了：

Harness Engineering。

最后，我们还希望 AI 不只是完成一次任务。

而是能够：

执行→ 检查→ 发现错误→ 修改→ 再执行。

于是又走向：

Loop Engineering。

所以你会发现，整个发展路径其实非常清楚：

Prompt → Agent → Tools/Skills → MCP → Harness → Loop

它背后真正发生的变化只有一件事：

AI 正在从一个“回答问题的软件”，逐渐变成一个“执行任务的数字员工”。

对普通职场人来说，这意味着什么？

如果你是开发人员，这 10 篇文章值得重点研究。

因为未来 AI 开发的重点，很可能不再只是“调用一个大模型 API”。

而是要设计：

Agent工具Skills上下文工作环境状态管理任务循环评估机制。

如果你是产品经理，你需要开始思考：

什么业务适合 Workflow？

什么业务才真正需要 Agent？

AI 可以调用哪些系统？

哪些决策必须由人确认？

失败后如何重试？

结果如何评估？

如果你是 HR、人力资源从业者，其实也没有必要研究论文公式。

但你需要关注一件更大的事情：

未来岗位所需要的能力正在发生变化。

企业真正需要的人，可能不只是“会用 ChatGPT”。

而是能够：

理解业务拆解任务配置 AI设计工作流调用不同工具检查 AI 输出让 AI 与企业系统协同工作。

如果你是运营、市场、销售、财务等普通职场人，同样如此。

未来真正拉开差距的，很可能不是：

“你会不会用 AI。”

而是：

“你能不能把自己的工作拆成一套 AI 可以参与执行的流程。”

最后

很多人现在学习 AI，还停留在：

“提示词应该怎么写？”

这当然有用。

但如果看完过去几年 AI Agent 领域最重要的一批研究，就会发现：

行业正在快速越过单纯的 Prompt Engineering。

真正值得关注的已经变成：

怎么给 AI 任务。

怎么给 AI 工具。

怎么给 AI 数据。

怎么给 AI 一个好的工作环境。

怎么让 AI 检查自己的结果。

以及——

怎么让 AI 从“给你一个答案”，变成“真正替你完成一件事情”。

这可能才是接下来几年，普通职场人最值得关注的 AI 能力。