模型会从单工转向多工

模型输出会从单条回答变成可按需取用的结构化多工结果。接口返回里会同时包含给用户看的内容、给工具用的状态、给流程用的动作和给业务目标用的判断；当 Harness 被模型更多承接，工具界面会变轻，数据资产、流程和业务目标会变重。

Thesis

未来模型会从单工转向多工。模型不该只吐出一段完整答案，而要同时产出可被不同层按需取用的结构：给人看的表达、给系统用的状态、给工具执行的动作、给业务目标校准的判断。

现在很多产品还把模型当成一个会写答案的接口。

输入一段 prompt，拿回一段文本，再由外层代码拆分、路由、提取和展示。这套方式能用，但它把太多结构放在模型外面。

产品要在回答之后再判断哪些是结论、哪些是行动、哪些该进数据库、哪些该交给下一个工具。我觉得这里会发生一次迁移：Harness 做的部分工作，会被模型自己接走。

Argument

单工输出的限制很直接：它把复杂任务压成一条线。

一条线适合聊天，不适合真实工作。真实工作里，一个输出经常同时服务几件事：用户需要一句解释，系统需要一组状态，工具需要明确参数，团队需要可追踪的记录，业务目标需要被重新校准。

今天很多 AI 产品靠 Harness 补这层结构。它包住模型，负责整理上下文、约束格式、拆动作、调工具、检查结果、再把内容塞回界面。

问题是，Harness 越重，产品越像在模型外面搭一个临时脚手架。每多一种场景，就要多写一层解析、路由和兜底。模型输出看起来是答案，系统需要的是一组可以被接走的结构。

多工模型的接口应该更接近一组并行语义流。它可以同时返回面向人的回答、面向流程的状态、面向工具的动作、面向数据资产的记录、面向业务目标的判断。调用方按需取用，不必把一段自然语言再拆成十个用途。

这会改变工具界面的定位。

过去界面很重要，因为人主要通过按钮、列表、表单和页面来组织工作。模型只负责一段回答，界面负责把工作装起来。

当模型输出本身带结构，界面就会变薄。它仍然要承载确认、编辑、选择和审计，但不再承担全部组织工作。很多原本靠页面关系表达的东西，会转到模型返回的结构、状态和动作里。

这时更重要的层会往下沉。

第一层是数据资产。模型要多工输出，必须知道哪些东西可复用、哪些记录可信、哪些上下文应该进入下一次任务。没有资产，结构化输出只会变成临时 JSON。

第二层是流程。多条输出流必须接到明确流程里，否则只是多生成几段内容。谁确认、谁接手、什么状态算完成、哪一步可以回滚，这些都要被流程承接。

第三层是业务目标。模型能同时做很多事以后，更需要知道哪一条线优先。没有目标约束，多工会变成更快的分叉。

模型多工之后，产品要管理的重点会从界面里的控件，转向输出背后的结构、流程和目标。