AI Agent从理想幻灭到长视野突然变好用的原因

你有没有发现一个奇怪的现象？

这背后发生了什么？为什么 Agent 在经历了几年的"不靠谱"之后，突然变得可用了？

从理想到现实：Agent 演进的三个时代

第一个时代：文本的搬运工

早期的 AI 模型非常基础，它们只能做简单的"文本进、文本出"。想要它们完成复杂任务？几乎不可能。开发者能做的，只是把一些简单操作串联起来，形成所谓的"链式调用"。

这个阶段谈 Agent，更多是概念而非现实。

第二个时代：搭建复杂的脚手架

随着模型能力提升，开发者开始尝试让 AI 做决策。但问题是，模型还不够聪明，需要大量"脚手架"来辅助：

• 明确告诉它"现在该做什么决策了"
• 预设好各种分支路径
• 在关键节点显式询问选择

这就像扶着小孩子走路，每一步都得看着，生怕它摔倒。虽然比第一个时代进步了，但距离"自主 Agent"还很远。

第三个时代：终于能跑起来了

大约在 2025 年中期，一切开始改变。

那时候，Claude Code 开始流行，很多人发现它真的能帮忙写代码、改 bug、甚至重构项目。与此同时，其他专注长时间任务的 Agent 工具也开始崭露头角。

这些工具有一个共同特点：它们让 AI 在一个循环中持续运行，AI 自己决定接下来该做什么、该调用什么工具、该查阅什么信息。不需要人类预设复杂的流程，AI 自己就能"跑"起来。

到了 2025 年中下旬，很多开发者明显感受到了一种"氛围转变"。大家开始相信：可以把真正困难的问题交给 Agent，让它工作几小时甚至更久，然后得到有价值的结果。

为什么现在 Agent 突然能用了？

模型更聪明了

这是最直接的原因。新一代大语言模型，特别是具备推理能力的模型，在理解复杂任务、做出合理决策方面有了质的飞跃。

过去的模型就像个刚学会说话的孩子，你得手把手教。现在的模型更像个能干的助手，你说个大概，它能理解你的意图并自行规划。

"Harness" 成熟了

模型变聪明只是一方面，更重要的是，开发者逐渐摸索出了一套让 Agent 高效工作的"机制"（Harness）。

什么是 Harness？可以理解为 Agent 的"操作系统"。它不仅提供基础工具，还内置了很多最佳实践：

• 规划工具：帮助 Agent 分解复杂任务
• 压缩机制：当上下文信息过多时，智能精简内容
• 文件系统访问：让 Agent 能够读写文件，管理中间状态
• 针对性优化：根据不同模型的特点调优（比如有的模型擅长用 Bash 命令，有的更适合图形化工具）

这些 Harness 组件看似技术细节，实际上让 Agent 从"能跑"变成了"跑得好"。

最关键的洞察：一切都是上下文工程

有个术语精准概括了 Agent 开发的本质：Context Engineering（上下文工程）。

什么意思？

想象你在和一个健忘的助手对话。如果他记不住之前说过什么，你就得不停重复信息，效率极低。但如果他有一个精心整理的笔记本，记录了所有关键信息，并且知道什么时候该翻阅哪一页，那工作效率就会高得多。

Agent 就是这样。它能完成多复杂的任务，很大程度上取决于它"上下文"中有什么信息、这些信息如何组织。

• 压缩？是上下文工程
• 规划？是上下文工程
• 文件系统管理？还是上下文工程
• 子 Agent 协作？还是上下文工程

模型能力提升 + 精妙的上下文工程 = Agent 从理想走向现实。

Coding：Agent 的第一战场

目前为止，Long Horizon Agents 最成功的应用场景是什么？

Coding。

一位商业人士分享说，他用 Claude Code 在1小时内搭建了一个自动化邮件系统，每天早上告诉他需要优先回复哪三封邮件。类似的故事越来越多。

为什么编程任务特别适合？

任务明确，结果可验证

写代码有清晰的目标：实现某个功能、修复某个 bug、通过某个测试。Agent 做完后，你运行一下就知道对不对。

这种"明确性"让 Agent 有发挥空间，也让人类容易评估结果。

"初稿"的威力

这是一个关键洞察：Agent 的可靠性还达不到99%，但它能完成大量工作。

所以最佳应用场景是：让 Agent 生成"初稿"，人类审查和调整最终结果。

• 编程：Agent 写代码生成 Pull Request，人类审查后再合并
• 研究：Agent 生成报告初稿，人类编辑补充
• 客户支持：Agent 分析案例生成总结，人类客服参考后回复

这个框架巧妙地平衡了 Agent 的能力和限制。

文件系统的魔力

编程任务还有一个独特优势：天然涉及文件系统。

Agent 需要读取代码文件、修改内容、创建新文件、运行测试。而文件系统恰好是管理"上下文"的绝佳方式：

• 把历史消息存到文件里，需要时再查
• 大段的工具输出不直接传给模型，而是存文件让它按需读取
• 中间结果持久化保存，不占用上下文窗口

LangChain 的创始人表示，他强烈相信：构建 Long Horizon Agent 必须给予文件系统访问权限。这不仅对编程任务重要，对几乎所有长时间任务都适用。

但所有 Agent 都应该是 Coding Agent 吗？

这引出了一个有趣的哲学问题：

"Agent 的工作是让计算机做有用的事，而代码是让计算机做事的好方法。所以，所有 Agent 本质上都是编程 Agent 吗？"

目前答案还不清楚。

一方面，编程能力确实让 Agent 的能力大大扩展。会写代码的 Agent 可以处理更广泛的任务。

另一方面，今天的"编程 Agent"大多针对编程任务优化，还不是真正的"通用 Agent"。

也许未来的通用 Agent 会具备编程能力，但不意味着今天的编程 Agent 就是通用 Agent。这个问题，业界还在探索。

开发 Agent 和开发软件：有什么不同？

如果你问一个资深开发者"构建 Agent 和构建传统软件有什么区别"，很多人会笼统地说"它们不一样"。

但到底哪里不一样？

逻辑不在代码里了

传统软件：所有业务逻辑都写在代码中。想知道软件在某个情况下会怎么做？翻翻代码就清楚了。

Agent 应用：逻辑分散在两处——一部分在代码中，一部分在模型中。你无法只看代码就知道 Agent 会做什么，必须实际运行才知道。

这是最根本的差异：我们引入了一个不确定性系统（黑盒模型）到应用中。

Trace 成为新的"源代码真相"

这个差异带来了深远影响。

传统软件出问题，团队会说："让我们看看 GitHub 上的代码。"

Agent 出问题，团队会说："让我们看看 Trace（运行轨迹）。"

什么是 Trace？

就是 Agent 运行时每一步做了什么的完整记录：

• 它看到了什么信息（上下文）
• 它做了什么决策
• 它调用了哪些工具
• 得到了什么结果

在单一 LLM 应用中，出现错误响应时，你知道输入的 prompt 和上下文是什么（由代码决定）。

但在 Agent 中，第14步的上下文是什么？你不知道，因为取决于前13步可能拉取的任意内容。

所以 Trace 变得至关重要。它不再只是生产环境问题排查工具，而是从开发第一天就使用的"一等公民"。

迭代的本质变了

有人说"构建 Agent 更需要迭代"，乍一听像句废话——构建软件不也是迭代吗？

但深入看，迭代的本质确实不同：

传统软件的迭代：

• 你清楚知道软件会做什么
• 迭代是为了改进功能、优化体验
• 焦点是"软件应该做什么"

Agent 的迭代：

• 发布前你不确切知道它会做什么，只有一个大概想法
• 迭代是为了"校准"行为，确保可靠性
• 焦点是"让 Agent 实际行为符合预期"

这导致 Agent 开发需要更多轮迭代，更多调整提示词（Prompt）来修正行为。

Memory：下一个关键前沿

既然 Agent 开发需要这么多迭代来调整行为，那有没有办法让它"自己学习"，减少人工迭代？

这就是 Memory（记忆）的价值。

Memory 在哪些场景真正有价值？

并非所有 Agent 都需要 Memory。

❌ 通用聊天工具（如 ChatGPT）：

• 每次对话主题都不同：今天问编程，明天问美食，后天问旅行
• 没有重复模式，Memory 很难发挥作用
• 事实上，很多人不常使用 ChatGPT 的 Memory 功能

✅ 专用工作流 Agent：

• 比如你有一个"邮件助手 Agent"，每天帮你处理邮件
• 它会逐渐了解：你倾向于先回复哪类邮件、哪些人的邮件更紧急、你的回复风格是什么
• 这些知识积累下来，就成了真正的"护城河"

有位开发者分享了一个真实案例：

他原来有一个带 Memory 的 Email Agent，用得很顺手。后来他把 Agent 迁移到新平台，新平台虽然有相同的起始设置和工具，但没有历史 Memory。结果？新 Agent 的表现糟糕极了，他甚至还没完全切换过去，因为新 Agent 相比旧的"差太多了"。

Memory 让 Agent 从"通用工具"变成了"你的专属助手"。

Agent 如何学习？

最激动人心的是，现在的 AI 已经有能力"查看自己的运行轨迹（Trace），分析哪里做得不好，然后修改自己的代码或指令"。

想象一下这个场景：

1. 白天，你的 Email Agent 处理了20封邮件
2. 晚上，它自动回顾今天的所有 Trace
3. 发现有3次你修正了它的决策
4. 它分析原因，更新自己的指令文件
5. 第二天，它在类似情况下表现更好了

这被称为"Sleep Time Compute"（睡眠时间计算），就像人类晚上睡觉时大脑整理白天的记忆一样。

Agent 自我改进的闭环正在形成。

未来会怎样？

核心算法的简洁与优雅

LangChain 创始人 Harrison Chase 说了一段很有意思的话：

换句话说，Agent 不需要特别复杂的架构，核心就是这么简单。但要让这个简单的理念真正工作，需要模型足够聪明，需要精妙的上下文工程，需要合适的工具和 Harness。

现在，我们有了。

从编程走向通用？

编程任务是 Long Horizon Agent 的第一战场，但不会是最后一战场。

研究、客户支持、内容创作、数据分析……很多领域都开始看到 Agent 的身影。关键是找到那些适合"初稿模式"的场景：Agent 做大量工作生成初稿，人类审查调整最终结果。

至于"所有 Agent 都是编程 Agent 吗"这个问题，答案还在探索中。但可以确定的是，给 Agent 访问文件系统、甚至代码执行能力，会大大扩展它们的应用范围。

UI 会如何演进？

Long Horizon Agent 运行时间很长，不可能坐在屏幕前等待。所以未来的 Agent UI 可能是：

1. 异步管理：像管理 Jira 任务一样，启动多个 Agent 同时工作
2. 同步对话：当某个 Agent 完成初稿，你可以切换到聊天模式给反馈
3. Workspace 视图：查看 Agent 修改的状态（代码文件、文档、数据等）

就像 Anthropic 的 Claude Cowork：你为 Agent 指定一个"工作目录"，它在那里操作，你随时可以查看进展。

这个目录可以是文件系统，可以是 Google Drive，可以是 Notion——任何存储状态的地方。你和 Agent 在这个"共享空间"中协作。

现有公司能跟上吗？

这让人想起一个历史问题：当软件从本地部署（On-Prem）转向云服务时，很少有本地软件公司成功转型。原因？构建云软件和本地软件根本不同。

现在，构建 Agent 应用和传统软件开发也根本不同。那么，现有软件公司能跟上吗？

年轻团队的"白板"优势

确实，很多 Agent 工程团队偏年轻化。年轻人没有固有观念关于"软件应该怎么构建"，更容易接受新范式。

但这不意味着资深开发者就跟不上。事实上，很多资深开发者很快适应了 Agentic 编程方式。这更多是一个思维模式问题，而非年龄问题。

数据是真正的护城河

对现有公司来说，最大的优势是什么？

数据和 API。

如果你是一家金融软件公司，有大量历史交易数据、风险模型、合规规则。这些数据暴露给 Agent，就能让 Agent 提供巨大价值。

有从业者反馈：在 AI 时代，数据的价值不是降低了，而是在不断上升。

但单有数据还不够。Agent 需要"指令"——如何使用这些数据、如何处理特定场景、如何做决策。这些领域知识，正是现有公司的另一个潜在优势。

关键是：你能不能把这些知识整理成 Agent 可以遵循的指令？

回到开头的问题

AI Agent 为什么突然"能用"了？

答案是：不是突然，而是多年积累的量变引发了质变。

模型变得更聪明，开发者掌握了精妙的上下文工程技巧，Harness 变得成熟，我们找到了适合的应用场景（"初稿模式"），形成了新的开发工具链（Trace、Eval、Memory）。

这些因素交织在一起，让那个从一开始就存在的简单理念——"让 LLM 在循环中自主运行"——终于真正落地了。

Agent 不再是遥远的未来，而是现在进行时。

它们还不完美，还需要人类监督和调整。但它们已经能够处理越来越复杂的任务，工作越来越长的时间，产生越来越有价值的结果。

更重要的是，随着 Memory、自我改进等能力的加入，Agent 正在从"工具"进化为"助手"，从"执行者"进化为"协作者"。

这才刚刚开始。