当Agent学会“思考”而非“调参”，我们离通用AI还有多远

词元无限这家公司，成立1年融资3轮，前字节女高管带队，产品在编程榜上跑赢GPT-5。这个新闻让我在实验室里反复看了好几遍，不是因为融资速度，而是因为“跑赢GPT-5”这个结果本身。作为一个还在啃论文的研一新生，我最大的困惑是：为什么一个成立不到一年的公司，能在编程这类对逻辑严密性要求极高的任务上，超越GPT-5和Claude这种顶级模型？

超越GPT-5的Agent架构秘密

新闻里提到词元无限的核心产品AgentForge，在SWE-bench(编程类任务排行榜)上重登榜首。这个榜单我关注过，GPT-5和Claude 4都曾在此厮杀。但词元无限的做法很有意思，他们不是去优化模型参数，而是重新设计了Agent架构。

从新闻透露的信息看，AgentForge的核心思路是“最小化Agent”，即把大模型当作一个“思考引擎”，而非直接输出答案的工具。具体来说，它让模型先生成推理路径，再执行操作，最后验证结果。这听起来像ReAct模式，但细节上更激进。

[!tip] 技术细节

AgentForge的工作流程可以抽象为：

> def agent_forge(task):
>     plan = llm.generate_plan(task)  # 先生成计划
>     for step in plan:
>         action = llm.think(step, context)  # 思考每一步
>         result = execute(action)  # 执行
>         feedback = validate(result)  # 验证
>     return final_answer
> 

关键区别在于，它把“思考”和“执行”完全解耦，让模型专注于逻辑推理，而具体操作交给代码执行器。

这种设计让我想起一篇论文叫《Chain-of-Thought Prompting Elicits Reasoning in Large Language Models》，但词元无限把CoT又往前推了一步。他们不是让模型自己生成链式思考，而是强制模型在每一步都停下来，先思考再执行。这种“慢思考”模式，在编程这种需要精确性的任务上，确实比GPT-5的“快思考”更靠谱。

最小化Agent的工程启发

新闻里提到一个让我很兴奋的概念：“最小化Agent”。这听起来像软件工程里的“最小可行产品”，但词元无限把它用在了AI Agent上。

我理解这个概念的核心是：不要把Agent设计成一个“全能机器人”，而是把它设计成一个“思考者+工具集合”。具体来说，AgentForge的架构可以拆解为：

• 思考层：大模型负责推理、规划、决策
• 执行层：代码解释器、API调用器、文件系统等工具
• 验证层：自动测试、代码检查、结果验证

这种分层设计的优势很明显。首先，它降低了对大模型本身能力的要求。即使模型在某些任务上不够强，但通过“思考+执行+验证”的循环，可以逐步逼近正确答案。其次，它让Agent变得可解释。开发者可以查看每一步的思考过程，定位问题。

[!abstract] 对于研究者的启示

词元无限的做法让我想到一个问题：我们是否过度关注模型参数的提升，而忽略了架构设计的重要性？在学术圈，大家更习惯调参、刷榜，但这种工程化的思路，可能才是落地的关键。

从“大模型”到“好数据”的行业转变

新闻里还提到一个细节：词元无限正在构建一个“数据飞轮”，通过Agent在真实场景中的应用，收集高质量的反馈数据，反哺模型训练。这听起来很合理，但真正落地很难。

我注意到，词元无限在数据上做了两件事：

1. 人机协作的数据标注：不是简单让AI标注，而是让人类专家介入，确保数据质量

2. 多模态数据融合：在Agent执行过程中，同时收集代码、日志、报错信息等多模态数据

这让我想起吴恩达最近的一个观点：未来AI的发展，数据工程可能比模型架构更重要。词元无限的做法正是这个趋势的体现。他们不是堆算力，而是堆数据质量。

另一个值得关注的点是，词元无限在Agent开发工具链上的布局。他们推出了Agent开发框架、评测基准、Agent Store

原文链接：https://www.tmtpost.com/8083966.html