2025 年上半年，AI Agent 赛道最值得回味的信号，不是某个模型又刷了榜单，而是“林俊旸和 Manus，双双回到原点”这个说法在开发者圈子里被反复讨论。
如果把这个标题只当作新闻看，好像只是一个人的选择和一款产品的调整。但把它翻译成工程语言，意思就清楚了：在经历了 Agent 概念的集中爆发之后，行业终于开始认真回答“Agent 到底是什么、能稳定做成什么”这个基础问题。Manus 的走红证明了“交给 Agent 一个目标，它自己完成任务”这个需求是真实存在的；Manus 遭遇的争议同样证明：当一个 Agent 被放到真实任务里，模型能力、工具稳定性、任务边界和结果评估，每一个环节都可能成为瓶颈。
对开发者来说，这个话题比新闻本身更有价值。过去一年，很多人照着演示视频和教程搭 Agent，搭完发现效果不稳定：让它查天气可以，让它“帮我完成一份调研报告”就失控；在测试集上能跑，换一批问题就崩。原因往往是同一个：把 Agent 当成了“更强模型的提示词”，而不是“由模型驱动的一个软件系统”。
这篇文章不打算复述某个人或某个产品的故事，而是从工程角度拆解“回到原点”背后的技术问题。我会先讲清楚 Agent 到底是怎样的系统，然后带你把一个最小可运行的 Agent 完整跑起来，再给出评估、排错和工程化建议。读完你会对“Agent 能不能用”这件事有一个更可靠的判断标准。
1. “回到原点”到底在说什么
1.1 Manus 带来的是什么信号
Manus 是 2025 年初在中文技术社区和海外社区同时引发大量讨论的 Agent 产品。它最让开发者印象深刻的一点，是交互方式从“聊天对话框”变成了“任务派发”：你不用一步步教它怎么做，而是直接告诉它目标，比如“帮我整理一份关于某个行业的调研报告”，它会在自己的执行环境里完成资料搜索、信息筛选、报告编写，最后交付一份产物。
这种“目标式交互”带来了两个结果。一方面，它证明了通用 Agent 的产品形态是被用户接受的——大量用户愿意为了一个内测资格去排队。另一方面，它也把 Agent 的工程质量问题暴露在了聚光灯下：任务执行到一半卡住、对工具返回结果理解错误、长链路中上下文丢失、结果无法稳定复现。这些问题并不新鲜，在任何一个 Agent 开发者手里都会出现，只是 Manus 第一次让它们以如此大规模、公开化的方式出现。
所以“回到原点”的第一个含义，是产品叙事回归到工程现实。无论是林俊旸作为 Agent 热潮中技术从业者的缩影，还是 Manus 作为头部 Agent 产品的代表，他们回到的地方是同一个：不再谈论“什么都能做”，而是回到“这件事到底怎么做才稳定”。
1.2 所谓“原点”是哪三个点
我更愿意把“原点”拆成三层来看。
第一层是回到模型本身。无论 Agent 的外壳包装成什么样，它的推理上限仍然由底层大模型决定。模型看不明白用户意图，规划层再精致也没用。
第二层是回到工具调用。Agent 相对普通对话应用的本质变化，是它能够调用工具。工具调用是否稳定、工具返回是否结构化、工具之间如何组合，决定了 Agent 能完成多少真实工作。
第三层是回到工程确定性。演示视频里 Agent 永远一遍成功，真实系统里 Agent 需要重试、超时、日志、评估和回滚。没有工程确定性，“通用 Agent”就是演示 Agent。
这三层，恰好也是本文后面要展开的三条主线。
2. Agent 到底是什么：核心概念与常见误解
很多同学上来就写 Agent，但对“Agent 是什么”并没有形成一个可操作的判断。我们先花一点时间把概念钉牢。
2.1 一个可以执行的 Agent 定义
Agent 是一个能够感知环境、做出决策、执行动作并从结果中学习的系统。在当下的 LLM Agent 实现中，最常见的范式是 ReAct，也就是 Reason + Act。它的执行循环可以用一句话概括：模型先“想”，再“做”，然后把“
