选 Agent 框架那阵子，最让人纠结的往往不是模型答得够不够聪明，而是它能不能把一个模糊的目标拆成可执行的步骤，并在工具返回结果后接着往下走。腾讯这次放出的 Hy4 Preview，恰好把重点压在了这件事上：它的任务执行接口不再只是"你问一句、它答一句"的对话往返，而是让你把目标交给模型，由它自己规划步骤、决定何时调用哪个工具，再根据工具返回值衔接下一步决策。对正在做大模型应用的开发者来说，这个变化值不值得切换，关键要看它在工具编排和多步规划上到底怎么跑。
过去用模型做智能体，开发者通常得自己写一层"调度器"：先让模型回答，再手动判断要不要调工具，调完把结果塞回去，循环往复。模型本身更像一个被动的问答端点，规划和衔接的活儿大多压在应用层。
Hy4 Preview 的思路是把这部分能力往模型里收。按官方说明，这是腾讯混元团队新一代的混合专家旗舰模型，总参数量达到 770B、每个 token 激活约 49B，并提供到 1M 的上下文长度。参数规模和超长上下文本身不是重点，重点在于它是"为生产力而生"——官方把软件工程中的长程开发、办公分析里的跨文件协作、游戏开发中的多轮迭代都列为重点优化方向，这些场景的共同点就是任务链条长、需要反复调用工具并记住前面发生过什么。
对选型中的开发者来说，可以这样理解这次的定位差异：如果你的需求只是纯文本生成或一次性问答，这种"任务编排"倾向带来的收益有限；但如果你的应用本身就要让模型连续调用多个工具、根据中间结果改变后续动作，那它瞄准的正是你的痛点。
要让模型自主规划，第一步是接入方式。Hy4 Preview 兼容 OpenAI 的 Chat Completions 协议，同时也支持 OpenAI Responses、Anthropic Messages 等接口形态，这意味着存量代码大多只要改一下 base_url 和模型标识符就能接进来，不必重写整套调用逻辑。
base_url
目前主要有三条接入路径，可以按团队情况选：
hy4-preview
api_key
EMPTY
tencent/hy4-preview
接入之后，真正体现"任务编排"的地方在于你怎么描述任务。思路是把目标和可用工具一起交给模型：在请求里声明工具清单（每个工具的名称、用途和参数结构），然后用一句完整的目标描述当作用户消息，而不是把每一步都手把手拆给它。采样参数可以参照官方建议，把 temperature 设为 0.9、top_p 设为 1.0。
temperature
top_p
Hy4 Preview 还提供了 reasoning_effort 这类思考档位控制，但要注意不同接入路径的写法不一样：自建场景通过 extra_body.chat_template_kwargs 传入，默认是开启思考的高档位，也可以切到不思考的写法；走 TokenHub 则是另一套取值，并可通过关闭思考的开关实现。简单任务关掉思考能省 token，复杂的多步规划任务则建议保留默认的高档位，让模型有空间去拆解和推演。
reasoning_effort
extra_body.chat_template_kwargs
真正把智能体跑通的难点，从来不是"调一次工具"，而是"调完一次之后怎么接着走"。这正是从对话往返转向任务编排后最值得盯住的部分。
从官方的 function call 示例可以看出它的运转方式。假设用户的目标是查询两个城市的天气，模型不会一次把两件事混在一起，而是先返回一个 tool_calls，里面带着调用的工具名（比如查天气的函数）和结构化的参数（比如城市为北京）。应用层执行完这次调用，把结果以 tool 角色、带上对应的 ToolCallId 回传给模型。
tool_calls
tool
ToolCallId
关键在于回传之后：模型会结合刚拿到的返回值做一次判断，明确"北京已经查完，根据任务还需要查上海"，然后再发起下一次工具调用。换句话说，拆解步骤、读取上一步结果、决定下一步动作这一整个循环，是在模型内部完成规划、由应用层负责执行的协作关系，而不再是你在外面写死一堆 if-else。
这种模式对工程实现有两个直接影响。一是你的工具必须返回结构清晰、模型能读懂的内容，返回值越含糊，模型做下一步判断时越容易跑偏；二是会话历史要完整保留每一轮的 tool_calls、工具结果和模型的中间说明，这样模型才能"记得"任务进行到哪一步了——而 1M 的超长上下文，正是为这种长链条、多轮工具调用的场景留出的空间。
想判断它适不适合自己的项目，最快的办法是不急着上复杂业务，先搭一个最小闭环验证一遍。
先选一条接入路径把服务连通，用一个最简单的本地函数当工具，比如查询某个城市天气这类输入输出都清楚的任务。在请求里声明这个工具，然后给模型一个需要调用它的目标。接着在代码里写好接收 tool_calls 的逻辑：解析出模型要调的函数名和参数，本地执行，再把结果按 tool 角色回传。
真正要观察的，是模型拿到返回值之后的表现——它会不会主动判断任务是否完成、需不需要再调一次、最后能否把多次调用的结果整合成一个连贯的答复。如果你的任务里本来就有"查完 A 再查 B""拿到结果再决定下一步"这类分支，这个最小 demo 就能帮你看清它在你的场景里拆解和衔接得够不够稳。
把前面几点串起来，判断就比较清楚了。如果你的智能体项目本身就围着多步任务转——需要模型连续调用工具、根据中间结果改路线、还得在长链条里记住上下文，那 Hy4 Preview 瞄准的正是这类需求，OpenAI 兼容的接口也让迁移成本可控，值得搭个最小闭环先试。
反过来，如果你的业务只是纯文本生成或单轮问答，这种偏任务编排的能力用不太上，收益有限。另外要留意的是，这个版本目前处于 preview 阶段，接口、思考档位、端点等细节都可能调整，正式接入前最好以腾讯云 TokenHub 文档、OpenRouter 模型页和官方仓库的当前内容为准，别把 preview 期间的写法当成长期稳定的约定。
说到底，Hy4 Preview 把规划和工具编排往模型里收这一步，解决的是智能体最容易掉链子的中间环节。要不要换，不取决于参数多大、上下文多长，而取决于你的任务到底有没有那条需要模型自己接着往下走的链条。先用一个结构清晰的工具跑通一轮，答案自然就出来了。
Δ
Ctrl+D