Agent开发入门系列第 6 篇 · 读这一篇需要 6 分钟
系列导读：这个系列不追热点，只把 Agent 架构里那些密度极高、一次读不透的概念，一个一个拆开。
先讲一个我劝你千万别信的故事。
某公司听说"模型自己就会调工具了"，第二天开了个会，把 Agent 工程团队裁掉一半，理由写得很漂亮："决策都内化了，编排层就是历史包袱。"
三个月后线上开始出故障：模型跑到第 40 步开始飘，工具参数格式时对时错，日志里找不到完整的决策链路。招回来的人第一句话是——"不是模型不该自己做决定，是决定做完了没人接。"
"模型即 Agent"这句话是真的，只是被听成了另一句话。
一、"模型即 Agent"到底在说什么
模型即 Agent（Model as Agent）指的是：模型通过后训练，尤其是强化学习，把工具调用的决策策略内化为原生能力。
内化之后，下面四件事不再需要外部系统手把手教它：
- 自主决定是否调用工具 —— 该自己回答的，还是该伸手去查的
- 自主选择工具 —— 手里这一堆工具里挑哪个最合适
- 自主生成参数 —— 把自然语言意图映射成结构化参数
- 自主决定是否继续调用 —— 信息够了就收工，不够就再走一轮
注意这四条有个共同点：它们全是"决策"，没有一条是"执行"。 这个区分是全篇的立论基础。
二、Kimi K3：把决策策略写进参数
Kimi K3 的基本盘是：约 2.8 万亿参数的混合专家（MoE）架构、100 万 token 上下文窗口、原生视觉理解能力，以及始终开启的思考模式（thinking mode）。
想象一个专家团队：有人擅长数学推导，有人擅长多语言，有人擅长遵循复杂格式的指令。来了一道题，系统自动判断这次只需要其中几位专家上场，其他人不参与计算。
这就是 MoE——既保证能力，又不用每次让全部参数一起开工。这很关键：200～300 次连续工具调用意味着要处理几十万个 token 的中间轨迹，每次都激活全部参数，成本和延迟都撑不住。
K3 通过强化学习把工具调用的决策策略内化为原生能力，效果是能连续执行 200～300 次工具调用而保持思考一致性，远超多数模型在数十次调用后就开始退化的表现。长链调用会累积误差，每一步偏一点，几十步后轨迹就偏得没法看——K3 能撑住几百步，说明它内化的不是"单步调用的正确率"，而是长链中不漂移的目标保持能力。模型也做了针对性优化：面向长周期编程与 Agent 工作负载优化，发布时提供 K3 Max（面向对话与 Agent 任务）与 K3 Swarm Max（面向大规模并行处理）两个规格。作为开源模型，它在软件工程和 Agent 基准测试中展现出了可与顶尖闭源系统比肩的性能。
但这里有个必须分清的边界
这张图是本篇最重要的一张。 被强化学习写入参数的主要是——何时调用工具、调用哪个工具、传入什么参数、是否继续调用、如何串联长链调用。
以下部分不由模型参数直接实现：web_search 的真实搜索、code_runner 的代码执行、沙盒环境、工具调用的发起与结果回传、ReAct 循环基础设施。
这五项没有任何一项能被梯度下降算出来。搜索需要网络和索引，代码执行需要解释器和沙盒，调用发起需要协议、鉴权和错误处理，循环需要有人把结果追加工具进上下文。
Kimi 路径里，Formula 负责服务端工具执行，客户端仍然驱动"调用模型 → 追加工具结果 → 再次调用模型"这个循环。所以：
模型自主性提高，并不意味着编排循环和工程基础设施消失。
三、GPT-5.6：把循环搬到服务端
GPT-5.6 走的是另一条路：网络搜索、网页阅读、代码执行、数据分析、迭代研究、报告生成，全部通过 API 内置工具完成 Deep Research。
两条路径并排放，会发现：模型的决策部分两边一模一样（都由模型决定何时调用哪个工具），工具也都在服务端执行。唯一差别是——循环归谁驱动。
自由格式工具调用
传统工具调用要求参数严格符合 JSON 格式，原话很形象——"就像填表格一样有很多格式限制"。想让模型传一段 Python 代码或一条 SQL 查询，就得先变成合法 JSON 字符串层层转义。
**自由格式工具调用（Freeform Tool Calling）**允许模型直接向工具发送原始文本，在 API 中通过 type: "custom" 的工具类型声明。这里必须点明，否则很容易过度YY：
其本质是 API 参数格式的演进，不是模型架构改变。
模型还是那个模型，变的只是接口怎么表达它想说的话。这是接口工程的胜利，不是智能的胜利。
配合 Responses API 内置工具（网络搜索、代码解释器），"搜索 → 阅读 → 分析 → 再搜索"的闭环可以在服务端完成。
两个具体例子
例一：「东盟 10 国首都之间，最近的一对首都距离多少」 —— 自动搜索各国首都地理坐标，编写 Python 代码计算所有首都两两之间的大圆距离，找出最近的一对。
例二：「搜索最近一个月的比特币走势，做技术分析」 —— 从多个金融数据源获取实时价格，用技术分析库计算移动平均线、RSI、MACD 等指标，生成图表并给出交易建议。
整个过程只用了 3 次迭代、4 次工具调用。 这就是决策被内化之后的样子：模型不需要人告诉它"接下来该干什么"。
GPT-5.6 在研究开始前可能先问你：偏好的数据源、需要分析的技术指标、研究目的、输出格式、关键约束。
意图澄清用于缩小"用户表面表达"和"用户真实目标"之间的差距。 用户说"分析一下比特币"，真实目标可能是给客户写报告、判断入场时机、或者交作业——三种情况下的数据源和输出格式完全不同。这一步依然需要 Harness 参与，它体现为在模型自主行动之前插入一次确认。
服务端与客户端的边界
必须把话说准，不能过度推广：Responses API 路径中，搜索、代码执行和循环在服务端完成，客户端不必手写全部 ReAct 编排；但其他接入方式仍可能由客户端驱动循环，Kimi 路径就是明确的例子。
有一种说法是"用GPT-5.6 这类API，客户端不用再手写 ReAct 循环了"——这只对特定的 Responses API 路径成立。两条路径的共同点是：都由模型决定何时调用哪个工具，工具都在服务端执行。 区别只在循环归谁驱动。
四、Harness 是缰绳和挽具，不是枷锁
先把误解拆掉：Harness 不是为了限制模型。 它存在是为了做六件事——把模型能力引导到正确方向、提供上下文、提供工具、增加安全约束、验证结果、纠正错误。
第 1 篇打过一个比方：Model 是一匹马，Harness 是缰绳、挽具、马车和车夫。只会拉车的马不太需要车夫；能自己决定往哪跑、要不要跳悬崖的马，车夫就变成了必需品。模型越强、自主决策空间越大，出错时的影响范围也越大，因此越需要细粒度治理。
五、「苦涩的教训」与 Harness 的持续变化
Rich Sutton 那篇《苦涩的教训》几乎是这个行业的判词，三个核心判断：人类先验编码通常只能短期有效（模型强一点，你精心设计的规则就可能变成多余的限制）；通用搜索和学习方法能够随数据和算力扩展（凡是能被学出来的，迟早会被学出来）；外部工程结构可能被更强模型逐步内化（今天手写的脚手架，明天可能成为模型的一部分）。
听起来对 Harness 很不利。但我的看法是：方向认同，节奏务实。 原因是模型可能逐步吸收 Harness 中的能力，但真实业务中的约束、偏好和异常情况无法一次性全部内化——一个模型再强，也很难在第一次部署时就内化你公司那套奇葩审批流程和没人写进文档的历史遗留规则。
所以是三条同时进行：
- 模型暂时做不到的，由 Harness 补足
- 模型内化一部分后，Harness 减少对应的脚手架
- Harness 转向兜住新的能力边界
这不是等着被淘汰，而是职责跟着模型能力线移动。会用画笔的模型出现后，画笔不需要被教怎么握——但画布和"别画到墙上"这条规则还在。
六、Agent 的三层学习与更新机制
还有一个问题没解决：模型自己怎么变得更好？
上下文适应（当前任务内） —— 示例、当前状态、检索结果进入上下文，模型立即调整行为，但不改变下一次会话的持久状态。优点是快、便宜；局限是受上下文窗口限制、不持久保存、受信息组织方式影响。
外部产物更新（跨任务保留经验） —— 更新对象包括知识文档、Prompt、Skill、确定性程序、Harness 规则。可审计、可修改、可回滚、可控，但执行时仍需通过上下文或工具接口被 Agent 使用。这是工程手段能提供的确定性，也是模型参数给不了的东西（第 10 篇会展开）。
参数更新（后训练） —— 适用于难以显式表达的高维能力：医疗影像理解、自然语言风格、隐式决策策略。优点是泛化自然，缺点是部署成本高、更新周期长、可解释性较弱。
三者协同
上下文负责临场适应，外部产物负责可控积累，参数负责内化难以显式表达的能力。
三条路径不是互斥分类，而是不同时间尺度上的协同机制。
判断该用哪一层有个朴素的办法：先问这东西能不能写成文字或规则。 能，就放外部产物，顺带获得可审计和可回滚；不能但短期需要，就放上下文；连"怎么描述"都做不到，才值得付出代价去训练。
七、什么时候这个说法会失效
上面这套"模型内化决策、Harness 兜住执行"的叙事很自洽，但边界要说清楚。
第一，模型强到一定程度，Harness 确实会萎缩。 今天需要手写的工具选择启发式、格式纠错逻辑、失败重试策略，明天可能就变成模型的默认行为。如果 Harness 里堆的全是"模型本来就会但我们教了它"的东西，那它迟早要被删掉。
第二，自由格式调用有安全和解析代价。 省掉的是 JSON 转义的麻烦，增加的是执行前的审查难度——一段自由文本里可能藏着越权操作，也可能格式不合法。接口更灵活，责任更重。
第三，服务端闭环比客户端编排更难调试和干预。 客户端驱动时每一步都看得见，可以随时叫停；服务端闭环把这些藏起来了。出错时定位困难，紧急时也没有手刹。
第四，强化学习内化的决策可能"自作主张"。 内化的"何时调用工具"是一条从训练数据里学来的策略，它不知道你的业务规则。它在训练分布上很果断，在你的分布上可能很固执。
第五，Kimi 路径与 GPT 路径不可简单类比。 一个把循环留在客户端，一个把循环收进服务端，架构、调试方式、成本模型、可控性都不一样。照搬另一条路径的做法，是把结论当成了方案。
小结
这一篇只做了一件事：把"模型即 Agent"这句话，拆回到它真正成立的那一层。
模型即 Agent = 决策被内化（何时调 / 调哪个 / 传什么参 / 是否继续 / 如何串联）
模型即 Agent ≠ 基础设施被内化（搜索 / 代码执行 / 沙盒 / 调用发起与回传 / ReAct 循环）
Agent = Model + Harness（依然成立）
Harness 的立场：方向认同，节奏务实
三层机制：上下文临场适应 · 外部产物可控积累 · 参数内化高维能力
三条必须记住的判断：
- 内化的是决策，不是基础设施 —— Kimi 路径里，循环仍由客户端驱动
- "客户端无需手写 ReAct 循环"只对特定 Responses API 路径成立 —— 不是所有路径的通例
- 模型越强，Harness 越需要细粒度治理 —— 自主性放大的是能力，也是影响范围
如果只带走一句话：模型变强改变的是 Harness 的职责重心，不是 Harness 的必要性。
下一篇回到一个更具体的问题：工作流、自主 Agent，还是把两者混起来？
下一篇：《工作流还是自主 Agent：怎么选、怎么混》
关注这个系列，我会持续更新。觉得有用的话，欢迎点个赞——它会让我更有动力把下一篇写好。
