第1章:AI Agent 的本质
你大概已经听过一百次"AI Agent"这个词了。每个大模型厂商都在说自己有 Agent 能力,每个创业公司都在做 Agent 产品,甚至连招聘 JD 里都开始写"需要 Agent 开发经验"。
但如果有人问你:Agent 到底是什么?它和一个会调 API 的聊天机器人有什么本质区别?
这一章就来回答这个问题。不是给你一个可以背诵的定义,而是帮你建立一个判断框架——看到任何系统,你都能说清楚它是不是 Agent,以及它在"自主性光谱"上处于什么位置。
1.1 Agent 的严格定义:感知 → 推理 → 行动 → 反馈的自主循环
核心直觉
Agent 就是一个能自己决定下一步做什么的程序。你给它一个目标,它自己想办法完成——感知环境、想清楚该怎么做、动手执行、看看结果、再决定下一步。
经典定义
"Agent"这个词在 AI 领域有几十年的历史。Stuart Russell 和 Peter Norvig 在《Artificial Intelligence: A Modern Approach》中给出了最经典的定义 [1]:
An agent is anything that can be viewed as perceiving its environment through sensors and acting upon that environment through actuators.
翻译过来:Agent 是任何通过传感器感知环境、通过执行器作用于环境的实体。
这个定义有意写得很宽泛——人类是 Agent(用眼睛感知、用手行动),机器人是 Agent(用摄像头感知、用机械臂行动),软件也可以是 Agent(用 API 输入感知、用 API 调用行动)。
但光有感知和行动还不够。Russell & Norvig 进一步定义了理性 Agent(Rational Agent):
对于每一个可能的感知序列,理性 Agent 应该选择能最大化其期望性能度量的行动。
注意两个关键词:期望和性能度量。理性不等于全知——Agent 不需要每次都做出最优决策,但它需要基于已有信息做出合理决策,并且有一个明确的优化目标。
LLM 时代的 Agent 定义
到了大模型时代,Agent 的定义变得更具体了。
OpenAI 在 2025 年 4 月发布的《A Practical Guide to Building Agents》中给了一个简洁的定义 [2]:
Agents are systems that independently accomplish tasks on your behalf.
独立地、代替你完成任务。OpenAI 进一步用了一个类比来区分 Agent 和传统自动化:传统规则引擎像一份清单,按预设标准逐项检查;而 Agent 更像一个经验丰富的调查员,能评估上下文、考虑微妙的模式、在没有明确规则的情况下识别异常。
Anthropic 在 2024 年 12 月发布的《Building Effective Agents》中给出了更精确的技术区分 [3]:
Agents are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks.
关键词是 dynamically direct——LLM 动态决定自己的流程和工具使用。不是人写好了流程让 LLM 填空,而是 LLM 自己决定走哪条路。
四个核心要素
综合这些定义,一个 LLM-based Agent 需要具备四个要素:
┌─────────────────────────────────────────────┐
│ Agent 核心循环 │
│ │
│ 感知 ──→ 推理 ──→ 行动 ──→ 观察 │
│ ↑ │ │
│ └──────────────────────────┘ │
│ (循环,直到任务完成) │
└─────────────────────────────────────────────┘- 感知(Perception):接收用户指令、读取环境状态、获取工具返回的结果
- 推理(Reasoning):理解当前状况,决定下一步该做什么——这是 LLM 的核心贡献
- 行动(Action):调用工具、执行代码、发送请求、修改文件
- 观察(Observation):检查行动结果,判断是否达成目标,决定是否继续
这四个要素构成一个循环,而非单次调用。Agent 会反复执行这个循环,直到任务完成或判断无法继续。
举个具体例子:你让一个 Coding Agent "修复这个测试失败"。它的执行过程可能是:
- 感知:读取失败的测试日志
- 推理:分析错误原因——是断言值不对,追溯到某个函数的返回值有 bug
- 行动:修改那个函数的代码
- 观察:运行测试,发现还是失败——但错误信息变了
- 推理:新的错误是另一个边界条件没处理
- 行动:补上边界条件的处理
- 观察:测试全部通过,任务完成
整个过程中,没有人告诉它"先读日志、再改代码、再跑测试"。它自己决定了这个流程。这就是 Agent 和普通程序的本质区别。
常见误区
误区一:调用了工具就是 Agent。 不是。如果调用哪个工具、传什么参数、调用几次,都是代码预先写死的,那只是一个带工具调用的 Workflow,不是 Agent。Agent 的核心在于 LLM 动态决策。
误区二:多轮对话就是 Agent。 不是。ChatGPT 的标准对话模式是多轮的,但它不会自主执行任何操作——它只是在回答你的问题。Agent 需要能"做事",而不仅仅是"说话"。
误区三:Agent 必须完全自主。 也不是。现实中的 Agent 几乎都有人工介入点(Human-in-the-Loop)。完全自主只是光谱的一端。
1.2 Agent vs Chatbot vs Workflow vs Copilot:四者的边界与光谱
核心直觉
Chatbot 只会说话,Copilot 会建议但你来做,Workflow 按固定流程执行,Agent 自己决定怎么做。
Anthropic 的关键区分
Anthropic 在《Building Effective Agents》中把所有这些都归为"agentic systems"(智能体系统),但在内部做了一个关键的架构区分 [3]:
Workflows are systems where LLMs and tools are orchestrated through predefined code paths.
Agents are systems where LLMs dynamically direct their own processes and tool usage.
区别在于谁掌握控制权:
- Workflow:开发者写的代码掌控流程,LLM 只是流程中的一个节点
- Agent:LLM 掌控流程,代码只提供工具和约束
这个区分比看起来更重要。很多号称是"Agent"的产品,拆开看其实是 Workflow——代码决定了先做 A、再做 B、最后做 C,LLM 只负责每一步的具体内容生成。
四者对比
| 维度 | Chatbot | Copilot | Workflow | Agent |
|---|---|---|---|---|
| 核心功能 | 回答问题 | 在上下文中建议 | 按预设流程执行 | 自主完成任务 |
| 谁做决策 | 用户 | 用户(采纳建议) | 开发者(写代码) | LLM(动态决定) |
| 行动能力 | 无 | 有限(在宿主应用内) | 有(预定义的) | 有(动态的) |
| 自主程度 | 无 | 低 | 中(确定性的) | 高(概率性的) |
| 失败模式 | 回答错误 | 建议不好(用户兜底) | 流程不适配新场景 | 做错事(可能不可逆) |
| 典型产品 | 客服问答机器人 | GitHub Copilot 补全模式 | LangChain Chain | Claude Code、Devin |
用真实产品理解边界
Chatbot 的例子:网站上的客服问答机器人。你问它"退货政策是什么",它从知识库里找答案回复你。它不能帮你操作退货,不能查你的订单,不能做任何事——只能说话。
Copilot 的例子:GitHub Copilot 的代码补全模式。GitHub 官方文档把它描述为在 IDE 里提供 inline code suggestions:你写代码时,它在光标位置给出 ghost text 建议,你按 Tab 接受或忽略 [4]。它的默认姿态是"建议",不是"代你执行"。它当然可能逐步扩展出更强的 Agent 能力,但至少在补全模式下,它的核心仍然是辅助你写,而不是自己跑测试、开 PR、跨应用完成整段任务。
Workflow 的例子:一个 LangChain Chain,固定流程是"提取实体 → 查数据库 → 格式化响应"。不管输入是什么,都走同一条路。LLM 只负责"提取实体"和"格式化响应"这两步的具体内容,流程本身是代码写死的。
Agent 的例子:Claude Code 读你的代码库、编辑多个文件、运行测试、发现测试失败了再回去改、创建 commit——整个过程它自己决定该做什么。或者 Devin,接收一个任务后自己规划、写代码、调试、开 PR。
这是一个光谱,不是四个格子
现实中这四者之间没有非黑即白的界限。很多产品在不同模式下处于光谱的不同位置:
GitHub Copilot 在补全模式下是 Copilot,在 Agent Mode 下就变成了 Agent。ChatGPT 在普通对话时是 Chatbot,打开 Deep Research 后就更接近 Agent。Anthropic 的五种 Workflow 模式(Prompt Chaining、Routing、Parallelization、Orchestrator-Workers、Evaluator-Optimizer)虽然叫 Workflow,但 Orchestrator-Workers 模式中如果 Orchestrator 有足够的自主决策权,它就在向 Agent 滑动。
Anthropic 自己也说得很清楚 [3]:
Workflows offer predictability and consistency for well-defined tasks, whereas agents are the better option when flexibility and model-driven decision-making are needed at scale.
翻译:任务明确、需要一致性时用 Workflow;任务开放、需要灵活性时用 Agent。
常见误区
误区:Agent 比 Workflow 更高级,所以应该默认用 Agent。 恰恰相反。Anthropic 和 OpenAI 的工程指南都明确建议:从最简单的方案开始,只在必要时增加复杂度。Agent 的灵活性是有代价的——更高的延迟、更高的成本、更难预测的行为、更难调试的失败。很多时候一个写死流程的 Workflow 比一个"自主"的 Agent 更可靠、更便宜、更好维护。这一点会在第 2 章详细展开。
1.3 Agent 的发展简史:从符号 AI 到 LLM-based Agent
核心直觉
Agent 不是 GPT 时代的新发明。从 1950 年代开始,AI 研究者就一直在造"能自主行动的程序"——只是每个时代用的技术不同。
第一阶段:符号 AI Agent(1950s–1990s)
最早的 Agent 是用符号和规则构建的。
1957 年,General Problem Solver(GPS)。Newell 和 Simon 搞出了第一个通用问题求解器,用"手段-目的分析"(Means-Ends Analysis)来规划行动:看当前状态和目标状态的差距,找一个能缩小差距的操作,执行它,再看差距。这个思路到今天的 Agent 里依然能看到影子。
1971 年,STRIPS。Stanford Research Institute 的 Fikes 和 Nilsson 为机器人 Shakey 开发了 STRIPS 规划器 [5]。它用谓词逻辑描述世界状态(比如 At(robot, roomA)),用前置条件和效果定义动作,然后自动搜索一个动作序列来达成目标。STRIPS 的表示方法影响深远——1998 年的 PDDL(Planning Domain Definition Language)标准化了这种表示,至今仍是自动规划领域的通用语言。
1970s–1980s,专家系统。MYCIN(医学诊断)、DENDRAL(化学分析)等专家系统用大量 if-then 规则编码领域知识。它们能在狭窄领域表现出"智能",但有两个致命缺陷:规则需要人工编写和维护,且一旦遇到规则没覆盖的情况就彻底失灵。
这个阶段的 Agent 有一个共同特点:知识是手工编码的。这意味着它们无法从经验中学习,也无法处理模糊或开放的任务。
第二阶段:强化学习 Agent(2013–2022)
深度学习改变了游戏规则。Agent 不再需要人工编码知识,它可以从与环境的交互中自己学会。
2013–2015 年,DQN 打 Atari。DeepMind 的 Deep Q-Network 直接从游戏画面的原始像素学会了玩 49 款 Atari 2600 游戏,在其中大约一半的游戏上达到了人类水平 [6]。这是第一次证明深度神经网络可以替代手工特征,直接从感知到行动地端到端学习。
2016 年,AlphaGo 击败李世乭。深度神经网络(价值网络 + 策略网络)加蒙特卡洛树搜索,在围棋这个曾被认为"十年内 AI 无法攻克"的领域取得突破。后续的 AlphaGo Zero 更进一步:完全不用人类棋谱数据,纯靠自我对弈学会了下棋。
2020 年,Agent57。DeepMind 的 Agent57 成为第一个在全部 57 款 Atari 游戏上超过人类基准的深度强化学习 Agent [7]。
但强化学习 Agent 有一个根本限制:它们只能在训练过的环境中工作。让 AlphaGo 去玩 Atari?重新训练。让 DQN 去做客服?不可能。每个任务需要从头训练一个专门的 Agent,而训练本身需要大量的环境交互和计算资源。
第三阶段:LLM-based Agent(2022–至今)
大语言模型带来了一个质变:Agent 不再需要针对每个任务从头训练。一个预训练好的 LLM 天然具备语言理解、推理和规划能力,只要给它合适的工具和指令,就能处理之前从未见过的任务。
几篇关键论文标记了这个转变:
2022 年 5 月,MRKL Systems [8]。Karpas 等人提出了模块化的神经-符号架构:LLM 作为路由器,把查询分发给不同的"专家模块"——计算器、搜索引擎、数据库等。这篇论文第一次正式提出把 LLM 当作编排器而非直接回答器。
2022 年 10 月,ReAct [9]。Yao 等人(普林斯顿)提出了 Reasoning + Acting 的交替循环:思考(Thought)→ 行动(Action)→ 观察(Observation),不断循环。这成了 LLM Agent 的基础架构模式,几乎所有主流框架都实现了 ReAct 的某种变体。
2023 年 2 月,Toolformer [10]。Meta 的研究表明 LLM 可以通过自监督学习自己学会在文本中插入工具调用 token。这证明了工具使用不需要专门的训练阶段——模型可以"自学"。
2023 年 3-4 月,AutoGPT 和 BabyAGI。这是 LLM Agent 概念进入公众视野的时刻。AutoGPT 在几个月内拿到了 10 万+ GitHub stars,BabyAGI 作为"第一个自主 Agent"迅速走红。但它们也暴露了早期 Agent 的所有问题:幻觉循环、API 成本失控、无法完成真实任务。有评论者指出,他们"找不到一个 AutoGPT 能真正胜任的实际用例" [11]。AutoGPT 团队自己后来都移除了外部向量数据库支持——因为典型的运行根本产生不了那么多需要持久化的数据。
2023 年 8 月,Wang 等人发表了领域内第一篇系统综述《A Survey on Large Language Model based Autonomous Agents》[12],提出了四模块统一框架:Profile(角色)、Memory(记忆)、Planning(规划)、Action(行动)。
从 AutoGPT 的狂热到现在,LLM Agent 经历了一个典型的技术成熟过程:从"什么都能做"的幻想,到"什么都做不好"的幻灭,再到"在特定场景下真的有用"的务实阶段。
工程权衡
三代 Agent 技术并不是后者替代前者:
| 代际 | 优势 | 劣势 | 今天还在用吗? |
|---|---|---|---|
| 符号 AI | 可解释、确定性、可验证 | 需要手工编码知识,不能处理模糊性 | 是——规划、约束求解、规则引擎 |
| 强化学习 | 能从经验中学习,在封闭环境中表现极强 | 每个任务需要重新训练,需要大量交互 | 是——游戏、机器人、推荐系统 |
| LLM-based | 通用能力,零样本泛化,自然语言接口 | 不确定性高,幻觉,成本高,难调试 | 是——这本书的主角 |
实际上,最好的 Agent 系统往往是混合的:LLM 做推理和规划,但关键业务逻辑用确定性代码实现;Agent 做探索和决策,但执行结果用传统测试验证。
1.4 行业现状:怎么看,而不是只记结论
核心直觉
截至 2026.04,Agent 更像一个"局部已经跑通、整体仍然偏早"的赛道。最值得看的不是谁喊得最响,而是三件事:哪些能力已经被产品验证,企业到底有没有规模化,以及社区为什么到现在还不完全信它。
先看事实层:哪些信号比较硬
行业现状变化很快,所以这一节不追求给出一个永远正确的快照,而是先把"比较硬"的信号挑出来。
信号一:产品发布和能力迭代在明显加速,但安全透明度没有同步跟上。
MIT 牵头的 2025 AI Agent Index 统计了 30 个有代表性的 Agent 系统,其中 24 个是在 2024-2025 年间发布或获得重大 agentic 更新的;但在 13 个达到前沿自主等级的系统里,只有 4 个公开披露了专门的 agent safety evaluation [13]。这两个数字放在一起看,比单独看任何一个都更有意思:市场热度是真的,"会做事"也是真的,但"可审计、可解释、可治理"还远没跟上。
信号二:浏览器任务开始显出产品化希望,但开放式 computer use 仍然更难。
OpenAI 在 Computer-Using Agent 相关材料里公布的结果是:WebVoyager 87%,WebArena 58.1%,OSWorld 38.1% [14]。你不必死记这三个数字,本章真正要记住的是它们之间的落差。它说明同样叫"computer use",结构化网页任务和开放式桌面任务不是一回事。前者已经能看到明显进展,后者距离稳定上线仍然很远。
信号三:企业在试,但规模化还远谈不上普及。
这里最容易被带偏,因为不同机构的口径差异非常大。
- LangChain 的《State of Agent Engineering》 说,57.3% 的受访者已经有 agents running in production [15]。这个数字能说明 builder 圈子里热度很高,但样本本身就是 agent builders,天然更乐观。
- McKinsey 2025 State of AI 给出的图景更保守:23% 的受访者说所在组织已经在至少一个业务职能中扩展 agentic AI,另有 39% 处于实验阶段;但在任何单一业务职能中,规模化比例都不超过 10%。同时,只有 39% 的受访者说 AI 已经对企业级 EBIT 产生任何影响 [16]。
- Gartner 在 2025 年 8 月的新闻稿里给的是前瞻性预测,而不是现状普查:它预测到 2026 年底,40% 的企业应用会包含 task-specific AI agents,而 2025 年这一比例不到 5%;同一份材料也专门提醒,不要把 embedded assistants 误叫成 agents,这种做法它直接称为 agentwashing [17]。
把这几类来源放在一起看,得到的不是一个精确数字,而是一个更靠谱的判断:Agent 已经过了"完全是 demo"的阶段,但距离"大范围稳定规模化"还有明显距离。
再看经验层:社区到底在担心什么
官方调查能告诉你 adoption curve,社区讨论更能告诉你真实阻力在哪里。
HN 上那篇标题就很直白的帖子 "AI agents: Less capability, more reliability, please"(2025 年 4 月)[18],核心情绪不是反对 Agent,而是反对把不可靠的系统过早包装成"已经可用"。很多评论都在强调:自然语言接口的失败模式太多,先把一个任务做稳,比把十个任务都做半吊子更重要。
另一篇 "Don't trust AI agents"(2026 年 3 月)[19] 讨论的是评估口径。里面反复出现的一个观点是:如果一个 Agent 的效果只能靠漂亮 demo 或者粗糙 productivity 指标来证明,那它多半还没有真正进入工程化阶段。
还有那篇标题就带着火气的 "Do AI agents deserve all the hype they are getting?"(2026 年 2 月)[20]。它最有价值的地方,不是结论悲观,而是把一个经常被忽略的问题挑明了:很多争论其实在定义阶段就已经说不拢了。有人说的是"会自己调几个工具",有人说的是"能跨系统完成长任务",还有人把任何带自动化的聊天产品都叫 Agent。定义不清,讨论就很容易跑偏。
把这些社区讨论放在一起看,你会发现开发者最常抱怨的不是"模型不够聪明",而是下面这几件事:
- 任务边界不清,导致系统看起来什么都能做,实际上什么都不稳
- demo 很漂亮,但失败恢复、权限边界、人工接管没有讲清楚
- 指标选得太讨巧,只展示有利 benchmark,不展示真实环境里的代价
最后看判断层:我会怎么判断一个 Agent 方向是否成熟
如果你让我给一个保守但实用的判断框架,我会看四件事。
第一,看任务是不是有清晰的外部反馈。 Coding Agent 能跑测试,research agent 能交叉验证来源,service desk agent 能看工单是否闭环。这类任务最容易积累真实改进。反过来,"帮我自动处理一切办公室工作"这种目标太大、反馈太模糊,通常更容易沦为演示。
第二,看失败是不是容易被发现和纠正。 一个 Agent 就算只有 80% 成功率,只要失败能被快速识别、成本可控、回滚简单,它依然可能有价值。真正危险的是那种错了也不容易发现、错一次代价还很大的系统。
第三,看人是不是还在回路里。 现在很多真正能落地的 Agent,都不是"全自动替你做完",而是"它先推进大部分工作,在高风险节点把控制权还给你"。这不是退步,反而往往是产品成熟的表现。
第四,看 ROI 证据是不是来自真实流程,而不是概念炒作。 最值得重视的信号,不是融资新闻,不是发布会,不是排行榜,而是团队愿不愿意让它每天真跑,并持续为它补评估、补日志、补权限体系。
如果把前面的事实层和经验层合在一起,我自己的结论是:截至 2026.04,Agent 最成熟的方向不是"完全自主替代人类",而是在边界清晰、反馈明确、可验证、可接管的任务里承担越来越多执行工作。Coding、research、service desk、受限 browser automation 这些方向,已经能看到稳定价值;而跨系统、长链路、高风险、低可验证性的全自动 Agent,整体上还在比较早的阶段。
常见误区
误区一:"行业里观点不一致,所以 Agent 还不值得看。" 不是。观点不一致,恰恰说明这个赛道正在从概念热潮进入分化期。真正该做的不是站队乐观或悲观,而是学会分辨哪些证据更硬。
误区二:"只要 benchmark 分数高,产品就已经成熟。" 也不是。benchmark 很重要,但它回答的是"在某个任务集上表现如何",不是"你能不能放心把真实业务交给它"。中间还隔着权限、可观测性、失败恢复、成本和治理。
面试高频题
题目:请用一句话定义 Agent,并解释它与传统 Chatbot 的根本区别。
好的回答思路:
先给一句清晰的定义:
Agent 是一个由 LLM 驱动的系统,它通过感知环境、自主推理和执行行动来完成目标,而不是被动地响应单次请求。
然后说清楚和 Chatbot 的根本区别——不是功能多少的问题,而是控制权在谁手里的问题:
- Chatbot:用户发消息 → 模型回复 → 结束。控制权始终在用户手中,每一轮都需要用户发起。Chatbot 不会主动做任何事。
- Agent:用户给目标 → Agent 自己规划步骤、调用工具、检查结果、调整策略、循环执行,直到完成。控制权在 Agent 手中,用户只需要在关键节点审批。
加分点(展现深度的额外角度):
- 提到 Anthropic 的精确区分:Agent 的关键特征是 "LLM dynamically directs its own processes and tool usage"
- 指出这不是二元区分而是光谱——GitHub Copilot 在补全模式下是 Copilot,在 Agent Mode 下就是 Agent
- 提到 Agent 的灵活性是有代价的:更高的延迟、成本和不可预测性。不是所有场景都需要 Agent,很多时候一个确定性的 Workflow 更合适
- 如果能举一个自己用过的具体 Agent 产品(Claude Code、Cursor Agent Mode 等)来说明区别,会更有说服力
参考资料
[1] Stuart Russell, Peter Norvig. Artificial Intelligence: A Modern Approach. Prentice Hall.
[2] OpenAI. A Practical Guide to Building Agents. 2025-04-17. https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf
[3] Erik Schluntz, Barry Zhang. Building Effective Agents. Anthropic, 2024-12. https://www.anthropic.com/engineering/building-effective-agents
[4] GitHub Docs. GitHub Copilot code suggestions in your IDE. https://docs.github.com/en/copilot/concepts/completions/code-suggestions
[5] Richard Fikes, Nils Nilsson. STRIPS: A New Approach to the Application of Theorem Proving to Problem Solving. Stanford Research Institute, 1971.
[6] Volodymyr Mnih et al. Human-level control through deep reinforcement learning. Nature, 2015. https://www.nature.com/articles/nature14236
[7] DeepMind. Agent57: Outperforming the human Atari benchmark. 2020. https://deepmind.google/discover/blog/agent57-outperforming-the-human-atari-benchmark/
[8] Ehud Karpas et al. MRKL Systems: A modular, neuro-symbolic architecture that can route natural language to expert modules. 2022. arXiv:2205.00445
[9] Shunyu Yao et al. ReAct: Synergizing Reasoning and Acting in Language Models. ICLR 2023. arXiv:2210.03629
[10] Timo Schick et al. Toolformer: Language Models Can Teach Themselves to Use Tools. Meta, 2023. arXiv:2302.04761
[11] Tom's Hardware. Auto-GPT and BabyAGI Are AI's New Hotness, But They Suck Right Now. 2023.
[12] Lei Wang et al. A Survey on Large Language Model based Autonomous Agents. Frontiers of Computer Science, 2023. arXiv:2308.11432
[13] MIT. The 2025 AI Agent Index. https://aiagentindex.mit.edu/data/2025-AI-Agent-Index.pdf
[14] OpenAI. Computer-Using Agent. 2025-01-23. https://openai.com/index/computer-using-agent/
[15] LangChain. State of Agent Engineering. https://www.langchain.com/state-of-agent-engineering
[16] McKinsey. The State of AI: Global Survey 2025. https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai
[17] Gartner. Press release, 2025-08-26. Gartner Predicts 40 Percent of Enterprise Applications Will Feature Task-Specific AI Agents by 2026, Up from Less Than 5 Percent in 2025. https://www.gartner.com/en/newsroom/press-releases/2025-08-26-gartner-predicts-40-percent-of-enterprise-apps-will-feature-task-specific-ai-agents-by-2026-up-from-less-than-5-percent-in-2025
[18] Hacker News. AI agents: Less capability, more reliability, please. 2025-04. https://news.ycombinator.com/item?id=43535653
[19] Hacker News. Don't trust AI agents. 2026-03. https://news.ycombinator.com/item?id=47194611
[20] Hacker News. Do AI agents deserve all the hype they are getting? 2026-02. https://news.ycombinator.com/item?id=46923790