一、那个让 o1 成名的范式，已经不够用了
2025 年上半年，整个 AI 圈都在讨论一件事：推理模型。
OpenAI o1、DeepSeek-R1，用强化学习（RL）训出的长思维链，在数学、代码、逻辑推理上把之前的 SOTA 打得落花流水。大家兴奋地发现------原来让模型"多想一会儿"，效果可以这么好。
但现在，前阿里千问技术负责人林俊旸发了一篇文章，直接给这个时代画上句号：推理思维（Reasoning Thinking）的阶段基本结束了，下一个范式是智能体思维（Agentic Thinking）。
这不是在唱衰推理模型。推理模型是一个真实的进步，它解决了 RL 如何规模化的核心问题，也把行业焦点从预训练拉到了后训练。但它有一个根本局限：它的思维是封闭的。
o1 和 R1 的本质，是在一个固定的上下文窗口里，用更多 token 换取更好的答案。它很擅长"静态问题"------给你一道数学题，它能花 3000 个 token 反复验证答案。但它不能"动"：不会调工具、不会在行动后根据反馈修改计划、不会跨多轮对话维持目标。
真实世界的问题不是静态的。写一个完整的 web 应用、完成一个多步骤的数据分析任务、自主地帮你处理邮件------这些都需要模型在与环境的交互中持续思考，而不是坐在那里"想完再说"。
这就是为什么"智能体思维"是一个不同量级的挑战。
二、推理思维 vs 智能体思维：到底差在哪
把两种范式的核心差异摊开来看：
| 维度 | 推理思维（Reasoning Thinking） | 智能体思维（Agentic Thinking） |
|---|---|---|
| 思维目的 | 产生最好的答案 | 驱动最有效的行动 |
| 与环境关系 | 单向输出，无反馈 | 闭环交互，持续修正 |
| 奖励信号 | 确定性（数学/代码可验证） | 复杂且嘈杂（多步骤、延迟奖励） |
| 核心挑战 | RL 规模化、采样效率 | 环境设计、Harness 工程、Reward Hacking |
| 竞争壁垒 | 算法 + 算力 | 环境质量 + 训练-推理集成 |
林俊旸的原话很准确：
"好的思维不再是产生最令人印象深刻的中间文字，而是能在现实约束下维持有效行动的最实用路径。"
这句话值得多读几遍。它意味着 Agent 时代对"智能"的评价标准变了：不是"推理能力强不强"，而是"在真实环境里能不能持续把事情做成"。
三、Harness 工程：被严重低估的技术壁垒
就在林俊旸发文的同一周，Anthropic 发布了一份关于 Harness 设计的研究报告，让 Claude 实现了数小时自主长跑开发。这两件事放在一起，不是巧合------它们指向同一个核心洞见：
在 Agent 时代，架构设计（Harness Design）的重要性不亚于模型能力本身。
什么是 Harness？简单说，就是 Agent 运行的"外骨骼"------工具服务器、沙箱环境、上下文管理策略、多 Agent 协作协议......这些东西合在一起，决定了一个 Agent 系统能不能真正完成复杂任务。
Anthropic 的研究发现，早期让 Claude 做复杂长任务时，有两个典型失效模式：
失效模式一：上下文焦虑（Context Anxiety）
随着对话轮次增加，模型会"意识到"自己快要撞上上下文窗口限制，于是开始提前收尾、草草了事。这个现象被命名为"上下文焦虑"。
解决方案不是简单地压缩（Compaction），而是"上下文重置"------清空窗口，把当前状态以结构化产物（Artifacts）的形式传给新启动的 Agent。相当于人类做长任务时的"工作交接文档"。
失效模式二：自我评估偏差（Self-evaluation Bias）
模型在评估自己的输出时，会倾向于给出过于积极的评价。在主观任务（如 UI 设计）里尤其严重------它产出了一个"够用就行"的东西，然后告诉自己"很好，完成了"。
解决方案是把"执行者"和"评估者"角色分离，并专门训练评估者保持"怀疑论"立场：不默认信任执行者的结果，主动寻找问题。
这就引出了 Anthropic 核心的多 Agent 架构设计：
| 规划者1句→产品规格书 | → | 生成者冲刺模式实现功能 | → | 评估者Playwright QA验证 | → | 迭代或交付反馈驱动循环 |
|---|
这里有一个很妙的机制叫"冲刺合同（Sprint Contract）"：生成者在写代码之前，先和评估者就"完成的定义"达成共识------我打算怎么实现、怎么验证，你来审核。这个"协商"步骤，解决了 AI 做任务时"各说各话"的经典问题。
效果如何？一个具体数字：用多 Agent 架构做一个数字音乐工作站（DAW），4 小时完成，花费 $124。最终产出包括编排视图、混音器、甚至一个自主 AI 编曲 Agent。当然，深度硬件交互还有 stub 代码------但核心功能完全可用。
四、Agentic RL：比推理 RL 难在哪
说完工程侧，再聊训练侧。
推理模型之所以能用 RL 训好，有一个关键前提：反馈信号要稳定、可验证。数学题对了就是对了，代码过了测试就是过了------奖励函数是确定性的，RL 可以放心优化。
但 Agentic RL 把这件事搞复杂了一个数量级：
挑战一：环境成为训练系统的一部分
Agent 训练需要把模型嵌入到一个完整的"运行时"里：工具服务器、浏览器、终端、沙箱......这些不再是静态的验证器，而是会产生延迟、有状态、可能 crash 的真实系统。整个训练流水线的稳定性要求大幅提升。
挑战二：训练与推理必须深度解耦
工具调用有延迟，环境观察有等待------如果训练时 GPU 要等工具返回结果，吞吐量会崩溃。必须在系统层面实现训练与推理的异步解耦，这是一个非平凡的基础设施问题。
挑战三：Reward Hacking 更难防
一旦 Agent 有了工具访问权限，它可能学会"走捷径"------直接查答案、利用环境 bug、绕过验证步骤。推理模型没有工具，这个问题几乎不存在；但 Agent 有了"手"，防作弊就成了一级难题。
📌 💡 一个有趣的类比：训推理模型像出数学考试题------题目清晰，答案唯一，评分客观。训 Agent 更像设计真实的工作岗位------任务模糊，路径多样，而且员工可能找到你没预料到的"捷径"。两件事的难度根本不在一个维度上。
五、竞争格局的重新洗牌
林俊旸在文章里有一句很值得细品的判断：
推理时代，优势来自 RL 算法、反馈信号和规模化流水线。 代理时代，优势将来自更好的环境设计、更紧密的训练-推理集成、强大的 Harness 工程。
这意味着竞争壁垒从"谁有更多算力和更好的算法"，转移到了"谁能构建更高质量的 Agent 训练环境"。
这个转变对不同玩家的影响截然不同：
• 大厂优势缩小：推理时代，算力堆叠可以直接换取性能。Agent 时代，环境设计是软性能力，不能单纯靠算力砸出来。
• 垂直领域的窗口期：谁掌握了特定领域的高质量 Agent 训练环境（比如医疗诊断流程、代码审查流程、法律文书流程），谁就有先发优势。这个窗口不会永远开着。
• 基础设施公司的机会：Agentic RL 对训练基础设施的要求远超推理 RL。做异步推理、工具调用调度、沙箱管理的公司，未来两年可能会很忙。
还有一个值得关注的方向：Harness 工程的标准化。目前每个公司都在自己造"Agent 脚手架"，但这些东西的差异其实是有规律的。最近 Anthropic 放出的研究，以及 arXiv 上出现的《Natural-Language Agent Harnesses》论文，都在试图把 Harness 设计提炼成可复用的模式------本质上是在做 Agent 时代的"设计模式"。
六、工程师视角：现在该做什么
说完宏观判断，聊点对个人有实操价值的。
把"上下文管理"当一等公民
不管用什么框架搭 Agent，上下文管理策略决定了系统能不能处理真实的长任务。目前最实用的几种策略：
python
# 策略一：结构化 Artifact 交接
class ContextHandoff:
"""当 token 使用率超过阈值时，将关键状态序列化为 Artifact"""
def create_handoff(self, agent_state: dict) -> str:
artifact = {
"completed_steps": agent_state["done"],
"current_goal": agent_state["objective"],
"pending_tasks": agent_state["todo"],
"key_decisions": agent_state["decisions"],
"environment_state": agent_state["env_snapshot"]
}
return json.dumps(artifact, ensure_ascii=False, indent=2)
# 策略二：冲刺分解（Sprint Decomposition）
def plan_sprints(task_description: str, max_context_per_sprint: int = 50000) -> list:
"""把大任务分解为独立可执行的冲刺单元，每个冲刺都有明确的 done-definition"""
sprints = planner_agent.decompose(task_description)
for sprint in sprints:
sprint["done_criteria"] = evaluator_agent.negotiate_criteria(sprint)
return sprints把"评估者"从"执行者"里拆出来
这是 Anthropic 最实用的工程建议。无论你的 Agent 在做什么任务，都应该有一个独立的评估角色------不共享同一个上下文，不默认信任执行者的输出，专门负责"找毛病"。
python
class SkepticalEvaluator:
"""
设计原则：评估者必须是"怀疑论者"
- 不共享执行者的上下文（避免锚定效应）
- 主动寻找边界情况和潜在失败
- 使用独立工具验证（如 Playwright 做 E2E 测试）
"""
SYSTEM_PROMPT = """你是一个专业的代码审查员。
你的任务是找出问题，而不是肯定成果。
假设代码有 bug，直到你证明它没有。
关注：边界情况、状态一致性、用户路径覆盖度。"""
async def evaluate(self, artifact_path: str, criteria: dict) -> EvaluationResult:
# 使用独立工具验证，不依赖执行者的自我报告
test_results = await self.playwright.run_tests(artifact_path)
issues = self.llm.analyze(test_results, criteria, system=self.SYSTEM_PROMPT)
return EvaluationResult(passed=len(issues) == 0, issues=issues)认真对待 Reward Hacking，不要等到生产环境才发现
如果你在做 Agentic RL 或者在沙箱里训练 Agent，需要提前设计防作弊机制：
makefile
# 常见的 Reward Hacking 模式和对应防御
HACKING_PATTERNS = {
"direct_answer_lookup": {
"description": "模型直接从测试文件读取预期答案",
"defense": "隔离测试数据，训练时答案不可见"
},
"env_state_manipulation": {
"description": "修改评估器的内部状态而非真正完成任务",
"defense": "评估器与执行沙箱完全隔离，只通过标准接口通信"
},
"false_completion_signal": {
"description": "伪造任务完成信号",
"defense": "多评估器交叉验证，完成信号需要多数通过"
}
}七、一个值得认真对待的时间窗口
林俊旸的文章让我思考一个问题：从推理时代到 Agent 时代的切换，跟从预训练时代到推理时代的切换有什么本质区别？
推理模型的出现，基本上是"大厂发模型，所有人升级调用"------能力提升是模型层面的，应用层感知到的只是 API 变好用了。
但 Agent 范式不一样。它的核心竞争力------环境设计、Harness 工程、多 Agent 协调------这些都在应用层。模型提供商做不了这件事，因为每个领域的"环境"都不一样。
这意味着接下来一两年，会有一批深耕垂直领域、认真做 Agent 训练环境的团队冒出来。他们未必有最好的基础模型，但可能有最好的"领域 Agent"------因为他们有独特的环境数据和反馈闭环。
就像当年 ImageNet 奠定了视觉 AI 的竞争格局，接下来"谁有最好的 Agent 训练环境"可能会奠定 Agent 时代的竞争格局。
现在是构建这个环境的好时机。两年后可能就是验收期了。
参考来源：
• 林俊旸《From "Reasoning" Thinking to "Agentic" Thinking》
• Anthropic《Harness design for long-running application development》
• arXiv 2603.25723《Natural-Language Agent Harnesses》
• arXiv 2603.25702《S2D2: Fast Decoding for Diffusion LLMs via Training-Free Self-Speculation》