论文标题：《Language Agents: From Next-Token Prediction to Digital Automation》
本文关键词：Reasoning | CoT的组块化设计 | 评估驱动设计 | Next token prediction | 模型泛化能力
一、基于泛化能力的AI能力演进
开始我们有了语言模型，它可以做文本生成任务
随后有了『大语言模型』，它基于文本的先验泛化能力，可以做翻译、QA、总结任务。
在『大语言模型』基础上，构建reasoning空间，定义环境，再加上工具、记忆、判断规则，构建更稳定的Agent体系。
二、用自组织的系统代替规则
通过将“策略组合”-->动作执行的条件，使模型具有更强的泛化性。
在具有reasoning能力的模型中强调“边界”，比强调“步骤”更重要。
三、系统中的环境
环境有内部的（intrinsic）也有外部的（extranel）。
内部的环境空间：通用知识、记忆、上下文、内在推理空间。
外部的环境空间：模型动作作用的空间，例如一个网页、一堆数据。
Defined by the environment——环境定义了动作空间和状态空间，限制模型的动作。
外部的动作空间：Agent可执行的操作，如点击、悬停
外部的状态空间：例如页面的HTML结构、当前URL等
内部的动作空间：写入、读取、更新记忆或知识
内部的状态空间：知识库、文件、函数工具箱🧰
Fixed by the environment——内部环境空间和外部环境空间都需要给予反馈，这种反馈要是明确的。
不同的人有不同的flavor（风格），我从很早就有一个偏好：我想定义一个基于结果的reward（奖励），而不是基于过程的；而且这个reward应该是基于规则、可计算的，而不是来自人的偏好、模型的偏好，或者一些黑盒指标。
我们做WebShop的时候，最困难的一点是，怎么定义reward。我觉得做任何RL（强化学习）任务最难的不是建环境，而是怎么设计reward。你当然可以把Amazon或Facebook模拟出来，工程上确实很难，但总是可以做。但最难的，是怎么设计一个既有难度，又有实际价值，同时又有一个好的reward的任务。
Reasoning能力
1. Reasoning是什么：是通过自然语言在内部环境里进行推理的过程。潜空间指的是推理的内容和结果在没有实际行动时，不会影响真实世界。另外，推理的边界是无穷的。
2. 为什么需要Reasoning：
总之是，就像射箭一样，没有精确瞄准就射出的箭是没法回头的。
目前用LLM做工具调用时也会出现相似问题：
LBM团队《ToolRM: Outcome Reward Models forTool-Calling Large Language Models》的文章提到：
现有的许多模型在预训练和微调时在做“下一个 token 的似然最大化”。
而调用的时候，JSON、AST参数表是一种全局一致性对象，而LLM的 softmax 是局部贪心（或采样），不保证整体是可执行的函数调用（类型、必填项、单位范围、调用顺序都不在 token 级目标里）。只要偏了一两个 token，工具调用就失效。
函数选择是“类别判别”任务而非生成任务：从N个工具里选1个，本质近似多分类；但 LM 是通过生成函数名字符串完成的，同义相近的名字很容易混淆（get_weather vs weather_lookup）。
槽位填充需要强类型语义：例如 date: ISO8601、currency: USD、count: int>=1，LLM的隐式表示不天然对类型和范围敏感，最容易错在数值、时间、单位转换、ID 引用。
多步推理时，Reasoning-Action的工作方法，使得信息可以在推理和实际行动的结果中不断流动，模型通过行动获取更多信息，获得更好的输出。解决线性的Next Token Prediction机制下存在“说出第一个字就无法更改，只能顺着往下说”情况，因为这种情况可能导致一些探索性的任务失效。
3. PM需要关注的Reasoing设计——根据业务逻辑对思维空间做模块化设计。
Yao在评估思维链颗粒度时，基于思维树做过三个颗粒度的探索尝试和实验，发现以Token思考错误率太高，完整进行思维思考又消耗太高
- Token as Thought：以Token作为一次思考
- Equation as Thought：以方程作为一次思考
- Reasoning as Thought：以单次推理作为一次思考
以coding场景为例，由粗到细可以被分为整个代码内容、单个函数、单个循环逻辑、单行代码、单个Token。
Yao 设计中隐含的训练框架包括：
组合性 ：利用思想（例如方程）的模块化特性，从更简单的单元组成复杂的推理，增强法学硕士处理多步骤问题的能力。
评估驱动设计（Evaluation-Driven Design）：使用可扩展的评估（详见下一部分）来评估思维树，其中每个节点（思想）都通过基于执行的指标（例如，方程正确性）进行验证。这与 InterCode 等基准测试一致，其中状态变化和输出指导训练。
权衡优化（Tradeoff Optimization）：根据任务复杂性调整思想的粒度——生成时粒度细，评估时更粗略——以平衡计算成本和准确性
可拓展性评估指的是一种自动化的、基于执行的评估方法，允许对庞大的任务分布中的Agent表现进行系统、低干预的基准测试。这种可拓展性评估无需人工手工判定和介入，只需要在 Docker 容器上运行就能得到Agent运行任务的结果（往往用成功率、错误率等指标表现）。
为达到这一目标，需要清晰、准确的最终状态判定条件。这要求从业者从终局出发，用规则化、白盒化机制给模型做reward。算数、代码、购买特定商品等任务均有明确的判定条件，是低垂的果实，各家厂商都在跟进，设计了SWE-Bench、GSM-8K等评测集。
目前对 “生成类任务”（无明确标准答案 /ground truth）的评估仍会回到 “无法实现 Automatic reward” 的老问题，这也是后续 agent 评估需要突破的方向。
目前的解决方案：
对常见的主观任务，如情感陪伴、疗愈、职业规划等，用提示词固化主观打分标准，使用模型做Auto Eval，这一能力在各大云平台上均有提供（eg百度云千帆的Auto Prompt和火山引擎的AutoPilot功能）
定义客观指标，比如在生成英文文本时使用不同难度级别单词的比例、生成人物时候
追踪归因到结果上
举一个最近看到的韩瞳老师书中的描述的易拉罐问题作为例子：
我有一个叫“罗比”的『机器人』️，它的世界（用计算机模拟，但是很脏乱）是二维的，到处是丢弃的易拉罐。我将用遗传算法为罗比进化出一个“脑”（即控制策略）。
罗比的工作是清理它的世界中的空易拉罐。罗比的世界由10 × 10的100个格子组成（图9.2）。罗比在位置（0,0）。我们可以假设周围围绕着一堵墙。许多格子中散落着易拉罐（不过每个格子中的易拉罐不会多于一个）。
罗比不是很聪明，看得也不远，他只能看到东南西北相邻的4个格子以及本身所在格子中的情况。格子可以是空的（没有罐子），或者有一个罐子，或者是墙。例如，在图9.2中，罗比位于格子（0,0），看到当前格子是空的，北面和西面是墙，南面的格子是空的，东面的格子中有一个罐子每次清扫工作罗比可以执行200个动作。动作可以是以下7种：往北移动、往南移动、往东移动、往西移动、随机移动、不动、收集罐子。每个动作都会受到奖赏或惩罚。如果罗比所在的格子中有罐子并且收集起来了，就会得到10分的奖赏。如果进行收集罐子的动作而格子中又没有罐子，就会被罚1分。如果撞到了墙，会被罚5分，并弹回原来的格子。
显然，罗比尽可能地多收集罐子，别撞墙，没罐子的时候别去捡，得到的分数就最高。
在随机探索的过程中，罗比可能重复撞墙，PM要做的事情是，制定一些人工规则：如果撞到了右边的墙，下一个动作不应该继续向右。但真实世界中的“墙”很难定义，需要PM的判断，例如商业化场景下的adload上限、统计口径的获取、数据披露的规则、平台内容的导向。
