最近看到“林俊旸和 Manus双双回到原点”这个话题时不少开发者都在讨论一个曾经刷屏的 AI Agent 产品以及围绕它产生的种种期待为什么在热度过去之后反而回到了更冷静的位置。作为一个长期关注大模型应用和自动化工具的技术博主我更关心的其实是这个“原点”到底指什么——是产品形态的原点是技术路线的原点还是我们对“智能体”这个概念本身的预期原点。这篇文章不打算讨论具体人物的个人故事也不去还原某条商业新闻的细节而是想从技术视角认真拆解一下Manus 这类通用 AI Agent 为什么能火为什么又会快速褪去光环以及作为开发者和产品设计者我们能从中沉淀出哪些真正可复用的经验。文章会包含 AI Agent 的核心概念拆解、通用架构分析、一个最小可运行的 Agent 示例代码、常见失败场景排查以及工程落地时的稳定性建议。如果你正在研究大模型应用开发、Agent 工作流设计或者想搞清楚“爆火 AI 产品背后的技术真相”这篇文章应该能给你一个比较完整的参考。1. 回到原点先看清 Manus 和 AI Agent 的本质1.1 一次爆火背后的技术事实2025 年 3 月前后Manus 出现在公众视野中。它被很多人描述为“通用型 AI Agent”在一段演示视频里它能够自主完成简历筛选、房产调研、股票分析这类多步骤任务而不是像传统聊天机器人一样只会“回答问题”。当时邀请码一度成为稀缺资源二手平台甚至出现高价代购整个行业对“AI 自动完成任务”的想象被彻底点燃。但热潮来得快去得也快。随着越来越多人真正上手体验大家发现它并不总是稳定任务步骤多了会中断工具调用会失败输出结果也不总是可复现。于是舆论开始从“AI 要取代打工人”转向“AI Agent 也不过如此”。这就是标题里说的“回到原点”。技术圈经常经历这样的周期新概念出现 → 舆论过热 → 体验落差 → 理性复盘。而回到原点的真正含义是大家重新把注意力放回 Agent 系统的工程本质它如何感知、如何规划、如何调用工具、如何验证结果、如何保证可靠性。1.2 什么是真正意义上的 AI Agent在继续往下之前我们需要界定一下 AI Agent 这个概念。很多人会把“聊天机器人”和“Agent”混为一谈但这两者其实是不同层级的产品。聊天机器人做的事情是“生成回复”它根据用户输入直接输出文字整个交互过程是“一问一答”的平面结构。虽然现在的大模型已经很强但它本质上仍然是“你说一句我接一句”。AI Agent 做的事情则是“完成任务”。它需要在理解目标之后自己拆分步骤选择工具执行操作观察结果然后决定下一步动作。换句话说Agent 是一个带“行动能力”的 AI 系统它不只说话还能做事。我们可以把 Agent 的核心能力拆成四个部分规划能力把一个大目标拆成多个可执行的小步骤。记忆能力记住用户目标、中间结果和历史交互信息。工具能力调用外部 API、数据库、浏览器、代码解释器等完成实际操作。反思与修正能力根据执行结果判断是否有偏差必要时调整策略。ChatGPT 这类产品也加入了工具调用甚至在 Agent 模式上做了很多尝试但广义上Agent 的核心不在于“有没有工具”而在于“系统是否具备自主决策闭环”。1.3 Manus 给出了什么新东西其实从底层技术来看Manus 并没有发明一种全新的 AI 模型。它更多是把已有的 LLM 能力、工具调度框架和任务管理流程组合成了一套产品。它真正贡献的是“产品交互范式”让用户不再直接面对模型对话框而是交付一个“任务目标”由系统替用户完成后续所有工作。这种产品形态并不神秘但它确实向普通用户展示了 AI 的另一种使用方式。技术圈早就知道 LangChain、AutoGPT、BabyAGI 这类框架也熟悉 ReAct 模式、Plan-and-Execute 模式但 Manus 把这些技术封装成了更贴近普通用户的产品。这正是它的价值。所以我们可以总结一下Manus 本身是一个产品层面的创新而不是模型层面的颠覆。理解这一点就能明白它为什么火得快、回落得也快——因为产品体验一旦达不到宣传中的“全自动”预期用户的失落感就会非常强烈。2. AI Agent 的典型架构拆开看看“自动完成”是怎么实现的要想真正理解这类产品我们需要站在工程角度拆解一个 Agent 系统的内部模块。下面是一个经过简化的通用架构其实很多开源项目和商业产品本质都在套用这个框架。2.1 一条任务的生命周期我们可以把一次完整的 Agent 任务执行分成下面几个阶段任务接收与目标理解 → 任务规划 → 子任务执行与工具调用 → 结果观察与验证 → 反思与修正 → 最终输出。每个阶段都有自己独立的技术难点。首先是任务接收与目标理解。这个阶段系统要解析用户输入识别意图提取关键约束条件。比如用户说“帮我整理一份北京适合看樱花的地点清单要求包含交通信息和门票价格”那么系统首先要知道目标地点是北京主题是樱花需要包含的信息字段是交通和门票。这个阶段通常会用到大模型的意图识别能力但直接让模型输出 JSON 结构可能会导致字段不稳定所以必须配合校验逻辑。其次是任务规划。系统要把一个复杂目标拆成多个可执行的子任务。这个过程既可以使用大模型直接生成计划也可以使用模板化策略。对于确定性比较高的任务比如“查询天气 → 生成穿衣建议”模板化策略更可靠对于开放型任务比如“帮我调研一个行业”则需要模型自主生成计划。然后是子任务执行与工具调用。这是 Agent 真正“动手”的环节。它可能调用搜索 API、打开数据库、执行代码、读取文件、发送请求等。工具调用的结果通常不是完美的可能包含缺失字段、错误信息、超时等异常Agent 必须具备处理异常的能力。接下来是结果观察与验证。Agent 拿到工具返回结果后不能直接把原始结果交给用户而是要判断结果是否满足任务要求。如果发现信息缺失或自相矛盾就应该进入反思阶段。最后是反思与修正。系统基于当前结果决定是继续、重试、更换工具还是直接结束任务。这是 Agent 区别于普通工作流的关键一环——它不是线性的而是有一个循环控制机制。2.2 两种主流设计模式ReAct 与 Plan-and-ExecuteAI Agent 领域有两种非常经典的模式几乎你想实现的任何 Agent 都可以归到这两类中。ReActReasoning Acting模式的核心是“边想边做”。它的循环逻辑是观察当前状态 → 推理下一步动作 → 执行动作 → 观察新结果 → 再推理。这种模式非常灵活适合任务路径不明确、需要动态决策的场景。缺点是模型需要在每一轮都做推理Token 消耗大而且容易出现循环不终止的情况。Plan-and-Execute 模式则分两个阶段。第一阶段先生成完整计划第二阶段按计划逐项执行。这种模式更稳定、更容易控制但缺点是计划一旦出错后续步骤全部受影响。很多生产系统会采用折中方案先生成计划再在执行过程中允许动态调整。从 Manus 这类产品的实际表现来看它更像是 Plan-and-Execute 的一种产品化封装。用户感知到的是“我给它一个目标它自动完成”而系统内部本质是把任务计划、调度、执行每一步都封装成了用户看不见的流程。2.3 工具调用层的设计要点Agent 系统的能力边界很大程度取决于工具层是否丰富、是否稳定。工具层是 Agent 的“手脚”没有工具大模型再聪明也只能纸上谈兵。工具层设计有几个核心问题。第一是工具注册机制系统必须知道有哪些工具可用、每个工具的入参和出参是什么第二是参数转换大模型输出的工具调用参数可能是 JSON 格式需要校验并转换成实际代码函数能接受的格式第三是错误处理工具可能抛异常、可能超时、可能返回空结果Agent 必须能识别这些情况第四是并发控制多个子任务可能同时执行要考虑资源和成本限制。很多 Agent 效果不稳定问题并不出在大模型本身而是工具调用层没有做足够的容错处理。举个例子Agent 调用一个天气查询接口返回数据里没有降水概率字段。如果代码不做字段校验直接访问data[precipitation]就会抛 KeyError整个任务中断。而一个健壮的系统应该捕获这种异常并让 Agent 重新选择查询策略。3. 自己动手实现一个“最小 Agent”核心循环纸上谈兵不如动手实践。下面我们用 Python 写一个精简但完整的 Agent 核心循环演示任务规划、工具注册、执行、反思与最终回答的全过程。这个示例不会依赖任何重量级框架用标准库加少量代码就能跑通目的是帮助理解 Agent 的工作原理。3.1 最小架构设计我们的 Agent 分成几个模块工具注册中心统一管理可用工具。任务规划器根据任务生成执行步骤这里使用简单规则 LLM 模拟。执行器按计划调用工具。验证器检查工具结果是否满足要求。主循环将上述模块串联起来支持最大步数和终止判断。为了演示这里我们不真正调用外部大模型 API而是用规则和模拟数据来模拟模型决策。如果用真实大模型你可以在规划器和执行器之间插入 API 调用。3.2 首先定义工具注册中心工具的注册机制是 Agent 系统的基础设施。我们定义一个register_tool装饰器让所有工具函数可以方便地注册到全局字典中。# 文件路径tool_registry.py import ast import operator # 全局工具注册表 TOOL_REGISTRY {} def register_tool(name: str): 将函数注册为 Agent 可用工具。 def decorator(func): TOOL_REGISTRY[name] func return func return decorator def get_tool(name: str): return TOOL_REGISTRY.get(name) def list_tools(): return list(TOOL_REGISTRY.keys())这里使用函数装饰器可以让我们在定义工具函数的同时完成注册维护起来比较方便。后续如果要增加工具只需要在模块任意位置定义一个新函数并加上register_tool(工具名)即可。3.3 编写两个演示工具我们实现两个工具一个安全的四则运算计算器一个模拟的数据查询工具。注意计算器这里没有直接使用eval而是用ast模块做表达式安全校验。在生产环境直接对用户输入使用eval是非常危险的必须做白名单限制。# 文件路径tools.py import ast import operator import random from tool_registry import register_tool # 允许的运算节点类型 _ALLOWED_NODES ( ast.Expression, ast.BinOp, ast.UnaryOp, ast.Constant, ast.Add, ast.Sub, ast.Mult, ast.Div, ) _OPERATORS { ast.Add: operator.add, ast.Sub: operator.sub, ast.Mult: operator.mul, ast.Div: operator.truediv, } def _safe_eval(expression: str): 限制表达式语法后执行避免任意代码执行。 try: tree ast.parse(expression, modeeval) except SyntaxError: raise ValueError(f无法解析表达式: {expression}) for node in ast.walk(tree): if not isinstance(node, _ALLOWED_NODES): raise ValueError(f表达式包含不允许的语法: {type(node).__name__}) def _eval_node(node): if isinstance(node, ast.Constant): if not isinstance(node.value, (int, float)): raise ValueError(只支持数字常量) return node.value if isinstance(node, ast.BinOp): left _eval_node(node.left) right _eval_node(node.right) if isinstance(node.op, ast.Div) and right 0: raise ValueError(除数不能为 0) return _OPERATORS[type(node.op)](left, right) if isinstance(node, ast.UnaryOp): operand _eval_node(node.operand) if isinstance(node.op, ast.USub): return -operand if isinstance(node.op, ast.UAdd): return operand raise ValueError(f不支持的语法节点: {type(node).__name__}) return _eval_node(tree.body) register_tool(calculator) def calculator(expression: str) - str: 计算数学表达式例如 (12 6) * 2。 try: result _safe_eval(expression) return f计算结果: {result} except Exception as e: return f计算失败: {e} register_tool(query_sales) def query_sales(region: str) - str: 查询指定区域的产品销量演示数据。 # 模拟固定种子便于复现 rng random.Random(region) base rng.randint(100, 1000) return f{region} 区域本月销量: {base} 件环比增长 {rng.randint(-10, 20)}%这个query_sales工具使用了固定种子随机数好处是相同输入可以得到相同输出便于我们后续演示和调试。实际项目中这里会替换成数据库查询或第三方 API 调用。3.4 构建 Agent 主循环接下来是 Agent 的核心逻辑。为了简化规划器使用了一套规则映射如果任务包含“计算”和“销量”就依次调用计算器和销量查询工具。在实际项目中这一步通常由大模型完成但核心流程是一样的。# 文件路径agent.py from tool_registry import TOOL_REGISTRY def plan(task: str) - list: 规划任务步骤演示版基于规则的简单规划。 steps [] if 计算 in task: steps.append({ tool: calculator, args: {expression: ((5 8) * 3 - 12) / 2}, purpose: 完成数学计算 }) if 销量 in task: steps.append({ tool: query_sales, args: {region: 华东}, purpose: 获取华东地区销量数据 }) if not steps: steps.append({ tool: calculator, args: {expression: 2 3}, purpose: 默认计算示例 }) return steps def execute_step(step: dict) - dict: 执行单个工具调用。 tool_name step[tool] tool_func TOOL_REGISTRY.get(tool_name) if not tool_func: return { tool: tool_name, success: False, output: f工具 {tool_name} 不存在 } try: output tool_func(**step[args]) return { tool: tool_name, success: True, output: output } except Exception as e: return { tool: tool_name, success: False, output: f工具执行异常: {e} } def run_agent(task: str, max_steps: int 10): Agent 主循环规划 - 执行 - 验证 - 反思。 print(f[Agent] 收到任务: {task}\n) steps plan(task) results [] for i, step in enumerate(steps[:max_steps], start1): print(f[执行] 第 {i} 步 - 工具: {step[tool]}) print(f 目的: {step[purpose]}) result execute_step(step) print(f 输出: {result[output]}) results.append(result) # 简单反思逻辑如果执行失败则补充一步计算器兜底 if not result[success]: print( 反思: 检测到工具执行失败尝试调用 calculator 兜底) fallback execute_step({ tool: calculator, args: {expression: 2 * 10}, purpose: 兜底计算 }) print(f 兜底输出: {fallback[output]}) results.append(fallback) print(\n[完成] Agent 执行流程结束) return results if __name__ __main__: import tools # 导入即注册工具 run_agent(计算一道表达式并查询华东地区销量)3.5 运行效果说明将上面三个文件放在同一目录下运行python agent.py预期输出大致如下[Agent] 收到任务: 计算一道表达式并查询华东地区销量 [执行] 第 1 步 - 工具: calculator 目的: 完成数学计算 输出: 计算结果: 15.0 [执行] 第 2 步 - 工具: query_sales 目的: 获取华东地区销量数据 输出: 华东 区域本月销量: 821 件环比增长 15% [完成] Agent 执行流程结束注意这里的销量数字是随机种子生成的每次运行可能保持一致但如果你换一个区域参数结果就会变化。这个最小示例虽然简陋但已经包含了一个 Agent 系统最重要的骨架工具注册、任务规划、执行调用、结果反馈和反思兜底。你可以在plan函数中接入大模型让模型动态决定调用哪些工具也可以在execute_step中增加超时机制和重试逻辑让系统更接近生产可用。4. 为什么热度会迅速褪去从工程角度看“回到原点”事实上Manus 的爆火和回落并不让人意外。站在工程角度我们可以把原因拆成几个层面。4.1 产品 demo 与真实场景的差距演示视频里的任务通常经过了精心筛选和多次调试Agent 在理想条件下确实表现得非常好。但用户拿到真实任务后输入的自然语言可能模糊、包含歧义、涉及私有数据、依赖特定业务背景这些都会显著降低 Agent 的成功率。举个例子演示中的“筛选简历”看起来很好用但真实场景中简历格式五花八门PDF 扫描件、图片型简历、不同语言的命名习惯都会让解析变得复杂。Agent 可以完成“从 100 份结构化简历中筛选出符合条件的人选”却很难处理“从一堆杂乱邮件附件中识别出候选人并提炼关键信息”这种真实任务。4.2 多步任务的误差累积问题Agent 执行任务时每一步都有失败概率。如果单步成功率是 90%那么一个五步任务的整体成功率只有 59%。而真实开放任务往往不止五步可能涉及十几个子任务整体成功率会指数级下降。这就是 Agent 系统面临的“误差累积”问题。解决思路通常是增加中间验证、允许人工介入、设计自动回滚机制。但产品要做到这些工程复杂度会大幅上升远不是给模型加一个工具调用功能就能解决的。4.3 Token 成本与访问延迟的约束Agent 的自主决策消耗的 Token 数量远高于普通对话。模型需要不断进行推理、输出工具调用 JSON、处理工具返回结果、再次推理每一轮都意味着成本增加。如果任务步骤多、工具返回内容长一次任务的成本可能达到普通对话的几十倍。同时延迟也是大问题。Agent 每一步都要和大模型服务交互一个任务可能需要几十次请求累计耗时通常以分钟甚至小时计。用户对“AI 自动完成任务”的预期是“几分钟内给出结果”但实际体验往往是“长时间等待后可能失败”这种落差很容易造成负面评价。4.4 可复现性与安全边界另一个被很多人忽略的问题是可复现性。大模型本身具有随机性Agent 又在这个随机性基础上叠加了多步决策导致两次输入相同任务可能得到完全不同结果。对用户来说这就意味着“这次成功不代表下次成功”产品可信度因此大打折扣。安全边界同样棘手。Agent 能够执行工具意味着它有了真实世界的影响力。如果 Agent 错误地执行了删除操作、发送了不合适的邮件、购买了错误商品结果会是灾难性的。在缺少严格权限控制和操作审批机制的情况下产品方很难放开手让 Agent 完全自主行动。5. 高频问题排查为什么 Agent 总是“跑偏”作为开发者如果你正在构建自己的 Agent 应用下面这些高频问题几乎一定会遇到。我把它们整理成了一张排查表。问题现象常见原因解决思路Agent 不调用工具直接给出文字答案模型自身倾向生成回复而不是工具调用工具描述不清晰优化系统提示词明确告知必须调用工具为工具补充详细描述和示例参数工具参数格式错误模型生成的 JSON 字段缺失或类型错误增加参数校验提供严格的 JSON Schema解析失败后让模型重新生成任务执行到一半中断单次任务超时工具调用异常未捕获设置整体超时和单步超时对异常工具调用做捕获并反馈给模型Agent 陷入死循环停止条件过于宽松反思逻辑缺少终止判断设置最大步数判断结果是否满足终止条件连续多次失败后强制退出结果不稳定、每次不一样大模型采样随机性规划路径不确定降低温度固定随机种子对确定性任务使用规则模板而非模型规划Token 消耗过高模型多次无效推理工具返回结果过长裁剪工具返回内容限制反思轮数使用更小的模型做简单分类使用了不安全的工具操作工具层缺少权限控制为工具增加操作白名单危险操作增加人工审批环节使用最小权限原则6. 工程落地建议从“能跑”到“能用的 Agent”很多团队做一个 Agent Demo 很容易但要让它在生产环境稳定运行需要额外投入大量工程工作。下面这些建议是我在实际项目中反复验证过比较有效的做法。6.1 用确定性兜底不确定性大模型的规划能力很强但它也是不可靠的。正确的做法不是让模型承担全部决策而是把业务逻辑拆解成“确定性流程 模型决策点”的组合。凡是能用规则判断的场景就不要让模型做选择凡是能用模板处理的内容就不要让模型自由发挥。比如一个客服工单分类任务你可以先用正则规则匹配常见关键词只有规则无法命中时才调用大模型分类。这样既降低了成本也提高了稳定性。6.2 工具描述要写清楚模型调用工具时全靠工具名称和描述来理解工具用途。很多开发者随便写一句描述结果模型频繁调用错误工具。工具描述应该包含工具解决什么问题、参数含义、参数格式示例、返回值说明、使用限制。比较好的描述示例工具名称: query_sales 参数: region (字符串区域名称例如 华东、华南) 功能: 查询指定区域最近一个月的销量数据和环比增长率。 注意: 只能查询已配置区域未配置区域会返回错误。如果工具描述能写成这种程度模型的工具选择准确率会明显提升。6.3 增加人工审批的“安全闸门”Agent 一旦具备执行能力就必须考虑操作风险。建议将工具分为“只读工具”和“写操作工具”两类。只读工具可以自主执行比如查询、搜索、计算写操作工具必须增加人工审批环节比如删除、修改、发送消息、提交订单。在生产系统中这种审批机制可以用消息队列实现Agent 发起写操作请求 → 进入待审批队列 → 人工确认后执行。虽然失去了“完全自动”的炫酷感但可靠性和安全性才是产品能不能长期运营的底线。6.4 记录完整执行轨迹当 Agent 执行失败时复盘能力非常重要。每一个任务都应该记录完整的执行日志包括用户原始输入、模型每一步推理结果、工具调用参数、工具返回内容、异常信息、最终输出。有了这些日志你才能快速定位是哪一步出了问题。我还建议增加“执行轨迹采样”功能定期把部分日志里的轨迹抽取出来分析哪些步骤最容易失败、哪些工具调用错误率最高、哪些提示词会导致模型走弯路。数据驱动的改进效率远高于凭感觉调参。6.5 把反馈闭环做进产品Agent 产品要在真实使用中不断进化就必须设计反馈闭环。用户标记的“不满意结果”应该回传到系统形成新的调试样本。常见的做法有两种一是让用户对结果做点赞/点踩二是对失败任务自动生成报告展示执行轨迹和失败原因。很多团队的 Agent 项目失败不是因为模型不够强而是因为缺少这种迭代机制。产品上线只是开始持续根据真实反馈优化工具描述、调整提示词、修正流程才是 Agent 应用的长期竞争力。7. 总结与下一步学习路线回到标题“林俊旸和 Manus双双回到原点”对开发者的启发其实不是“AI Agent 不行了”而是“AI Agent 才刚刚开始被正确认识”。爆火阶段被放大的期待最终在真实工程体验中回归理性。这个原点不是退步而是行业重新站在技术事实上讨论问题。通过这篇文章你应该掌握了以下内容理解了 AI Agent 与普通聊天机器人的本质区别。了解了 Agent 系统的核心组成规划、记忆、工具、反思。掌握了一个最小 Agent 的代码实现包括工具注册、任务规划、执行和兜底逻辑。清楚了 Manus 这类产品爆火后迅速降温的工程原因。知道了 Agent 开发中常见的问题排查思路和工程落地建议。下一步你可以从这几个方向继续深入第一深入学习 ReAct、Plan-and-Execute 等经典模式尝试用 LangGraph、AutoGen 或 OpenAI Function Calling 重写上面的 Agent 示例。第二研究 Memory记忆机制让 Agent 在多轮任务中保持上下文一致。第三探索多 Agent 协作架构了解不同 Agent 角色如何分工。第四关注 RAG检索增强生成技术把 Agent 与内部知识库结合起来解决私有数据场景的需求。如果你正在设计自己的 Agent 产品我的建议是先想清楚三个问题你的任务是否足够适合自动化你的工具层是否足够稳定你的失败恢复机制是否可靠把这三个问题想明白比追逐任何新技术热点都重要。最后留一个动手作业试着把上面示例里的plan函数从规则判断改成调用大模型 API让模型根据用户输入动态生成计划。再把query_sales工具替换成真实的数据库查询或第三方接口。做完这些你会对“Agent 系统真正落地”这件事有更深刻的体感。如果这篇文章对你理解 AI Agent 有帮助可以收藏备用后续我会继续输出大模型应用开发和 Agent 工程落地相关的内容欢迎关注讨论。