Agentic Thinking 拆解：自适应思考与连贯思考如何改变 Agent 任务链路

Agentic Thinking 拆解：自适应思考与连贯思考如何改变 Agent 任务链路

大模型从"会聊天"到"会干活"，中间横亘着一道任务链路鸿沟：面对一个需要浏览网页、读取文档、调用十余个函数、运行并调试代码的复杂任务，模型必须在何时思考、思考多久、如何把一次行动的结果反馈回下一步决策之间持续作出判断。传统做法是让外部框架（planner、orchestrator、ReAct 循环）替模型编排这一切，而 Agent 模型要走通端到端，就必须把"思考调度"本身内化成模型能力。

这正是 Nex-N2.5-Pro 所属的Agentic Thinking框架试图解决的问题。它以**自适应思考（Adaptive Thinking）与连贯思考（Coherent Thinking）**两条机制为骨架，配合多模态工具调用闭环，让模型在真实环境的长程任务中持续行动、自我修正。本文结合仓库源码（chat_template.jinja、config.json、processor_config.json）与官方基准数据，拆解这套机制的工程实现与任务链路价值。

一、两条思考机制的定位差异：调"要不要想"与"想得连不连贯"

Agentic Thinking 框架的核心，是把"推理预算"和"推理连续性"从隐式行为变成可配置、可观测、可干预的显式机制。Nex-N2.5 用同一个reasoning_effort参数区分出三种思考模式，对应仓库 README.md 中 "Thinking Modes" 一节：

自适应思考：把"思考预算"交给模型动态分配

自适应思考解决的是推理开销与任务复杂度错配的问题。若所有请求一律强制深度推理，简单指令会白白消耗延迟与 token；若一律不思考，复杂任务又会"脱口而出"地犯错。medium模式将决策权下放给模型：简单问答直接应答，疑难任务自动进入推理，思考量随任务难度伸缩。

这一机制在模板层有直接的工程对应。查看 chat_template.jinja 末尾的生成提示部分：

{%- if add_generation_prompt %} {{- '<|im_start|>assistant\n' }} {%- if reasoning_effort is not defined or reasoning_effort is none %} {{- '<think>' }} {%- elif reasoning_effort == 'none' %} {{- '<think>\n\n</think>\n\n' }} {%- elif reasoning_effort == 'high' %} {{- '<think>\n' }} {%- else %} {{- '<think>' }} {%- endif %} {%- endif %}

可以看到reasoning_effort直接驱动模板在<think>标签处注入不同的"思考起始状态"：none生成一个立即闭合的空思考块，模型被引导跳过推理直接作答；high打开思考块并换行等待模型填充推理内容；默认（medium）则不替模型预设思考长度。思考轨迹与最终答案之间用<think>...</think>显式隔离，为下游推理解析器（--reasoning-parser qwen3）的分离提供了稳定的格式锚点。

连贯思考：让推理轨迹跨越多次工具调用

自适应思考解决"想不想、想多久"，连贯思考则解决多步行动中推理是否断裂的问题。在 Agent 任务链路里，模型往往要连续发起多次工具调用——第一次调用的结果往往决定第二次调用的参数。若每次行动都被当作孤立回合处理，模型就会"失忆"，链路随之瓦解。

连贯思考的机制是：把每次工具调用前后的推理轨迹（reasoning_content）完整保留并回灌进上下文，使模型对"我为什么走到这一步、下一步做什么"保持连续认知。在 chat_template.jinja 的 assistant 消息渲染逻辑中，模板会先从消息内容里切出<think>块：

{%- if '</think>' in content %} {%- set reasoning_content = content.split('</think>')[0].rstrip('\n').split('<think>')[-1].lstrip('\n') %} {%- set content = content.split('</think>')[-1].lstrip('\n') %} {%- endif %}

随后将思考内容与工具调用一并封装进同一条 assistant 消息（<think>...</think>+<tool_call>...</tool_call>）。这意味着推理轨迹不是一次性草稿，而是与行动序列共同构成可回放、可延续的"思考-行动历史"——这正是连贯思考区别于普通 CoT 的关键：推理不只是为了让答案更准，更是为了给后续行动提供上下文锚点。

模板还专门处理了多步工具调用的消息折叠：当连续多条消息都是<tool_response>时，它们会被合并进同一个 user 消息块，避免"思考-行动-观察"循环中因消息结构碎片化而打断推理连续性：

{%- if loop.previtem and loop.previtem.role != "tool" %} {{- '<|im_start|>user' }} {%- endif %} {{- '\n<tool_response>\n' }} {{- content }} {{- '\n</tool_response>' }}

机制对比小结

二、端到端任务执行与能力迁移：从"会单步"到"会整链路"

自适应与连贯思考的组合，在工程上支撑了端到端任务执行：模型不需要外部 planner 代为拆解任务，而是自己完成"理解目标 → 规划步骤 → 调用工具 → 检验结果 → 调整计划"的完整闭环。这一点与社区对 Agentic Thinking 框架的观察一致——其核心卖点正是端到端执行与跨任务的稳定能力迁移。

MoE 架构：能力迁移的物理基础

端到端执行要求模型在同一条前向链路上同时承载规划、推理、工具协议、代码生成等多类能力，这恰恰是 MoE 架构的优势所在。看 config.json 的文本配置：

• 512 个专家、每 token 激活 10 个（num_experts: 512/num_experts_per_tok: 10），配合moe_intermediate_size: 1024的紧凑专家结构；
• 60 层混合注意力：每 4 层插入一个full_attention，其余为linear_attention（见layer_types与full_attention_interval: 4），在线性注意力承接超长上下文的低成本优势的同时，以全注意力层保证关键位置的精确建模；
• 262144 token 上下文（max_position_embeddings），为长任务链路中的完整"思考-行动-观察"历史提供存放空间；
• 采用FP8 块级量化（quant_method: compressed-tensors，FP8_BLOCK，权重按 128×128 块量化），使 397B 总参、17B 激活的 Pro 档（官方站点数据）能在 8×H100 单机上完成部署。

社区对 Nex-N2 系列的解析也印证了这一设计逻辑：MoE 的专家路由天然形成场景隔离——推理、代码、工具协议等子能力各占一组专家，任务类型切换时只需激活对应子集，能力迁移不必以牺牲既有能力为代价。这为 Agent 模型在"编码 → 浏览器操作 → 数据分析"之间平滑迁移提供了参数层面的解释。

基准数据：端到端链路能力的外化

端到端执行能力最终要落在长链路评测上。仓库 README.md 公布了 Nex-N2.5-Pro 在 Agent 与工具类基准上的成绩（temperature=0.7, top_p=0.95, top_k=40）：

值得注意的细节是 BrowseComp 的评测注记：当 token 用量超过上下文窗口 60% 时，采用 Summary 上下文压缩策略。这说明模型在超长链路中具备对历史上下文的主动压缩能力——这是端到端执行在 256K 上下文之外的另一道保险，避免长任务因上下文膨胀而提前"截断失忆"。

部署链路：把机制落到服务端

端到端能力最终需要通过推理服务暴露。仓库给出 Pro 档的标准部署（README.md "Docker Deployment"）：

docker run --gpus all --shm-size 32g --ipc=host \ -p 30000:30000 \ -v /path/to/your/model:/model \ nexagi/sglang:v0.5.18-nex-patch \ python3 -m sglang.launch_server \ --model-path /model \ --tp 8 \ --host 0.0.0.0 --port 30000 \ --reasoning-parser qwen3 \ --tool-call-parser qwen3_coder \ --chat-template /path/to/nex-N2.5-Pro/chat-template.jinja \ --mamba-scheduler-strategy extra_buffer

两个解析器参数分别对应前文的两条机制：--reasoning-parser qwen3负责把<think>推理轨迹从最终答案中分离（连贯思考的服务端出口），--tool-call-parser qwen3_coder负责解析工具调用结构（行动出口）。启动时显式挂载chat-template.jinja，则确保reasoning_effort参数在服务端被正确翻译为思考模式。

三、多模态工具调用闭环：思考-行动-观察的完整循环

端到端执行的最后一块拼图，是视觉反馈。Nex-N2.5 官方口径将这一点表述得很明确：视觉不再是单纯的输入模态，而是 Agent 感知环境、验证结果、推进任务的关键接口——模型操作电脑、浏览网页、运行程序之后，需要"看"到界面变化来确认行动是否生效，再决定下一步动作。这就是思考-行动-观察（Think-Act-Observe）循环。

多模态输入：环境感知的工程底座

看 processor_config.json：模型通过Qwen3VLProcessor统一处理图像与视频。图像侧使用 Qwen2VLImageProcessor（patch 16、merge 2），视频侧支持最多 768 帧、2 fps 采样（max_frames: 768、fps: 2），意味着模型不仅能看静态截图，还能消费短视频片段作为环境反馈。对应地，config.json 的vision_config定义了 27 层视觉塔（hidden 1152 → 投影到 4096），并保留image_token_id、video_token_id与vision_start/end_token_id等特殊 token。

这些视觉 token 在 chat_template.jinja 中被渲染为结构化占位：

{{- 'Picture ' ~ image_count.value ~ ': ' }} {{- '<|vision_start|><|image_pad|><|vision_end|>' }}

注意模板还会自动编号（Picture 1:、Video 1:），并且禁止在 system 消息中携带图像/视频（raise_exception('System message cannot contain images.')）——多模态内容只允许出现在对话侧，保证环境反馈不会被系统指令污染。

行动协议：结构化工具调用与反馈回灌

观察之后是行动。模板为函数调用定义了严格的 XML 式协议（见 chat_template.jinja 的 system 注入部分）：

<tool_call> <function=example_function_name> <parameter=example_parameter_1> value_1 </parameter> </function> </tool_call>

协议要求参数可跨多行，并明确"调用前可附自然语言推理、调用后不得追加解释"——这一约束正是为连贯思考服务的：推理放在调用之前，作为行动的动机与上下文；行动之后，<tool_response>以独立消息回灌，进入下一轮观察与思考。模板还要求每个函数参数tojson序列化，确保嵌套结构参数（JSON 对象、数组）在协议中无损传递。这套格式与服务端--tool-call-parser qwen3_coder配合，构成"模型发调用 → 解析器提取 → 执行器运行 → 结果回灌"的完整闭环。

闭环在基准上的体现

多模态闭环能力在电脑操作与视觉基准上得到直接验证。Nex-N2.5-Pro 的成绩（README.md）：

其中 OSWorld 类基准的评估由官方 NexCUA harness 完成，接地坐标统一归一化到 0–1000 刻度——这意味着模型输出屏幕坐标、执行点击/输入、再通过截图验证界面变化，正是"视觉反馈驱动自我修正"的标准动作序列。OSWorld-G 拿到同榜第一（87.4），从数据侧印证了"所见即行动"（Vision into Action）的闭环有效性。

结语：Agent 任务链路的范式位移

把三条线索拼起来，Agentic Thinking 的完整图景是清晰的：

1. 自适应思考把推理预算变成可调参数，让模型按任务复杂度弹性分配思考成本——解决"想太多"与"想太少"的两难；
2. 连贯思考让推理轨迹跨越工具调用持续存在，配合reasoning_effort、<think>切分与多步消息折叠，为长链路任务提供"不中断的思维流"；
3. 多模态工具闭环以视觉为反馈通道，用"思考-行动-观察"循环替代一次性问答范式，让模型在真实环境中持续行动、自我修正。

这三者不是并列的锦上添花，而是层层支撑的因果链：自适应思考决定行动的时机与深度，连贯思考保证多步行动的逻辑一致性，视觉反馈则让每一步行动都能被环境验证。Nex-N2.5-Pro 的仓库与基准数据表明，这一框架已经从架构设计（MoE 专家隔离、混合注意力、256K 上下文）、模板协议（chat template 的思考与工具封装）到服务化部署（reasoning parser + tool-call parser）形成了完整落地。对开发者而言，这意味着一件事：Agent 应用的编排逻辑，正在从外部框架向模型内部迁移——而这正是 Agent 任务链路的下一个范式。