如今智能体成了热点很多人比的仍是「谁的模型更大、更强」。真正决定能不能规模化落地的往往不是参数量而是每一次调用消耗多少 Token这些 Token 最后有没有变成调用方能用的结果。大模型时代Token 是生成文字的燃料。到了接入这一层它还是思考、工具调用和返回结果的计量单位。输入决定上游看见什么输出决定调用方拿到什么。推理、失败重试、缓存未命中都会变成持续消耗。要提高这些消耗对应的效率不能只多接几家模型而需同时推进输入约束、输出约束、Token 治理和路由工程行业竞争也在沿同一方向演进算力竞争(谁堆得动GPU)→模型能力竞争(谁更强、更通用)→Agent能力竞争(谁能稳定完成复杂任务)→Token智能效率竞争(谁用更少 Token 交付更复杂结果)。深兰正在做的就是模型前面的这一层不生产模型而是决定一次调用走哪条渠道、按什么协议出去、最后记在谁的额度上。一、Token 和智能体是燃料与发动机Token 决定 Agent 的表达和推理边界上下文够不够、推理链拉不拉得开、行动指令写不写得清。同样 1 万 Token可能打在失败重试上也可能打在一次成功的调用上。在我们正在落地的这层接入里渠道决定上游令牌和分组决定谁能调用、能用哪些模型模型映射把调用方的模型名落到具体上游。任务越长、重试越多消耗往往越高。可以把它想成Token 是燃料决定能力上限这层接入是发动机决定使用效率。燃料不够再强的上游也跑不远路由和计费太糙Token 再多也在空转。消耗 ≈ 任务复杂度 × 推理深度 × 行动次数 × 协作数量关键不是少调用而是把「语言生成成本」变成一次可结算的有效调用。输入 Token 决定上游知道什么输出 Token 决定调用方拿到什么。中间要经过鉴权、选渠道、协议转换、计费和记日志再把结果送回去二、输入 Token上下文构建与信息密度调用方看到的往往只是一次请求真正进入上游上下文的是请求体里的全部内容输入Token 用户意图 对话历史 任务上下文 知识检索 记忆 工具信息 规则约束Agent 越复杂系统提示词、历史和工具定义往往比用户那句话更占窗口。检索和记忆留在业务侧请求一旦进入我们这一层就会按 Token 计入额度。数量多不等于更聪明。真正起作用的是质量 × 相关性 × 组织方式。低质量 Token 只会加快扣费。下面六条是请求进入之前就要做好的事1.提示词压缩从长篇说明书变成最小必要指令集。超大请求在入口处被拦住。2.上下文工程采集 → 筛选 → 压缩 → 动态加载避免把知识、工具和历史一次写进请求。重复前缀应尽量命中缓存3.记忆压缩短期对话和长期记忆分开不要整段回放。用量日志用来对账不要再塞进下一轮上下文4.RAG 优化少召回、准召回。检索发生在进入之前送往上游的应当已是片段而不是整库5.工具按需携带本次用到的工具定义才放进请求。令牌上的模型限制用来收住能调用的范围6.多智能体协同不同角色使用不同令牌和分组额度和模型范围彼此隔离只传递结果摘要一句话输入优化拼的是信息密度。三、输出 Token从语言生成到任务执行普通模型用 Token 生成答案智能体调用在抵达上游前还带着规划、工具参数和多轮消息。思考预算、工具返回和失败后的再次调用都会扩大额度消耗。输出要变成调用方能解析的协议OpenAI、Claude、Gemini 之间的格式转换就做在这一层。降低输出消耗重点不是把回答写短而是让调用变成可执行结果思考力度按任务分级调用方不必为每家上游重写协议失败重试有次数上限。1.模型路由简单任务走轻量渠道复杂任务走大模型渠道。路径是任务识别 → 渠道与模型映射 → 加权选择 → 失败再换渠。2.推理优化想得更有效而不是想得更多。用思考力度或思考预算控制推理 Token3.工具调用工具参数保持结构化字段经协议转换后仍可被程序直接使用4.轨迹压缩日志留下模型、渠道、Token 和是否命中缓存不把整段过程再计进下一轮5.结构化输出用统一协议替代各家长篇方言使结果可被程序直接解析一句话输出优化拼的是结果密度。四、Token 治理从消耗品到可经营资产我们把上游的一次调用收成可分配、可结算的额度。治理落到六个动作预算、监控、权限、成本、质量、安全。目标只有一个在保证调用可用的前提下让Token可控、透明、高效、安全。• 预算用户额度和令牌额度给出上限。分组倍率决定同一笔用量实际扣多少。• 可观测看板和日志要能看到哪个模型、哪条渠道、是否命中缓存以及这次调用是否成功。• 权限正确的用户、正确的令牌、正确的分组、正确的模型范围。• 成本按量、按次和缓存命中分开计。渠道价格、缓存倍率和分组倍率用来对齐能力与账单。• 质量失败才重试重试次数有上限避免用重复调用掩盖上游故障。• 安全调用令牌和上游 Key 分开保管日志不记录可用密钥请求体设上限。要把这套治理运转起来还需要一条闭环采集 → 分析 → 预算 → 控制 → 优化 → 评估。这样 Token 才能从上游账单变成可度量、可优化的额度。五、工程协同Harness 与 Loop 的生命周期优化如果模型决定「智商」我们要决定 Token 怎么被鉴权、路由、转换、计费和记录——请求进入、选渠道、上游推理、结果返回、额度结算、日志退出。Loop Engineering 管的是循环本身。消耗大致来自重试次数 × 每轮上下文 × 推理输出 × 工具回传。优化不是把模型变弱而是从失败后原样重打大模型的 Token-rich Loop演进到加权选渠、有限重试、缓存复用、只在必要时换更大模型的 Token-efficient Loop。写在最后算力可以买模型可以换。深兰科技要拉开的差距是同一笔额度里能完成多少次有效调用。输入把信息密度做上去输出把协议和行动做稳治理让消耗变得可度量、可约束工程则让重试少空转。别再把 Token 只当成上游的计价单位而要当成可经营的数字能源。
DeepTalk|从算力内卷到智能效率：重新理解Agent时代的Token
如今智能体成了热点很多人比的仍是「谁的模型更大、更强」。真正决定能不能规模化落地的往往不是参数量而是每一次调用消耗多少 Token这些 Token 最后有没有变成调用方能用的结果。大模型时代Token 是生成文字的燃料。到了接入这一层它还是思考、工具调用和返回结果的计量单位。输入决定上游看见什么输出决定调用方拿到什么。推理、失败重试、缓存未命中都会变成持续消耗。要提高这些消耗对应的效率不能只多接几家模型而需同时推进输入约束、输出约束、Token 治理和路由工程行业竞争也在沿同一方向演进算力竞争(谁堆得动GPU)→模型能力竞争(谁更强、更通用)→Agent能力竞争(谁能稳定完成复杂任务)→Token智能效率竞争(谁用更少 Token 交付更复杂结果)。深兰正在做的就是模型前面的这一层不生产模型而是决定一次调用走哪条渠道、按什么协议出去、最后记在谁的额度上。一、Token 和智能体是燃料与发动机Token 决定 Agent 的表达和推理边界上下文够不够、推理链拉不拉得开、行动指令写不写得清。同样 1 万 Token可能打在失败重试上也可能打在一次成功的调用上。在我们正在落地的这层接入里渠道决定上游令牌和分组决定谁能调用、能用哪些模型模型映射把调用方的模型名落到具体上游。任务越长、重试越多消耗往往越高。可以把它想成Token 是燃料决定能力上限这层接入是发动机决定使用效率。燃料不够再强的上游也跑不远路由和计费太糙Token 再多也在空转。消耗 ≈ 任务复杂度 × 推理深度 × 行动次数 × 协作数量关键不是少调用而是把「语言生成成本」变成一次可结算的有效调用。输入 Token 决定上游知道什么输出 Token 决定调用方拿到什么。中间要经过鉴权、选渠道、协议转换、计费和记日志再把结果送回去二、输入 Token上下文构建与信息密度调用方看到的往往只是一次请求真正进入上游上下文的是请求体里的全部内容输入Token 用户意图 对话历史 任务上下文 知识检索 记忆 工具信息 规则约束Agent 越复杂系统提示词、历史和工具定义往往比用户那句话更占窗口。检索和记忆留在业务侧请求一旦进入我们这一层就会按 Token 计入额度。数量多不等于更聪明。真正起作用的是质量 × 相关性 × 组织方式。低质量 Token 只会加快扣费。下面六条是请求进入之前就要做好的事1.提示词压缩从长篇说明书变成最小必要指令集。超大请求在入口处被拦住。2.上下文工程采集 → 筛选 → 压缩 → 动态加载避免把知识、工具和历史一次写进请求。重复前缀应尽量命中缓存3.记忆压缩短期对话和长期记忆分开不要整段回放。用量日志用来对账不要再塞进下一轮上下文4.RAG 优化少召回、准召回。检索发生在进入之前送往上游的应当已是片段而不是整库5.工具按需携带本次用到的工具定义才放进请求。令牌上的模型限制用来收住能调用的范围6.多智能体协同不同角色使用不同令牌和分组额度和模型范围彼此隔离只传递结果摘要一句话输入优化拼的是信息密度。三、输出 Token从语言生成到任务执行普通模型用 Token 生成答案智能体调用在抵达上游前还带着规划、工具参数和多轮消息。思考预算、工具返回和失败后的再次调用都会扩大额度消耗。输出要变成调用方能解析的协议OpenAI、Claude、Gemini 之间的格式转换就做在这一层。降低输出消耗重点不是把回答写短而是让调用变成可执行结果思考力度按任务分级调用方不必为每家上游重写协议失败重试有次数上限。1.模型路由简单任务走轻量渠道复杂任务走大模型渠道。路径是任务识别 → 渠道与模型映射 → 加权选择 → 失败再换渠。2.推理优化想得更有效而不是想得更多。用思考力度或思考预算控制推理 Token3.工具调用工具参数保持结构化字段经协议转换后仍可被程序直接使用4.轨迹压缩日志留下模型、渠道、Token 和是否命中缓存不把整段过程再计进下一轮5.结构化输出用统一协议替代各家长篇方言使结果可被程序直接解析一句话输出优化拼的是结果密度。四、Token 治理从消耗品到可经营资产我们把上游的一次调用收成可分配、可结算的额度。治理落到六个动作预算、监控、权限、成本、质量、安全。目标只有一个在保证调用可用的前提下让Token可控、透明、高效、安全。• 预算用户额度和令牌额度给出上限。分组倍率决定同一笔用量实际扣多少。• 可观测看板和日志要能看到哪个模型、哪条渠道、是否命中缓存以及这次调用是否成功。• 权限正确的用户、正确的令牌、正确的分组、正确的模型范围。• 成本按量、按次和缓存命中分开计。渠道价格、缓存倍率和分组倍率用来对齐能力与账单。• 质量失败才重试重试次数有上限避免用重复调用掩盖上游故障。• 安全调用令牌和上游 Key 分开保管日志不记录可用密钥请求体设上限。要把这套治理运转起来还需要一条闭环采集 → 分析 → 预算 → 控制 → 优化 → 评估。这样 Token 才能从上游账单变成可度量、可优化的额度。五、工程协同Harness 与 Loop 的生命周期优化如果模型决定「智商」我们要决定 Token 怎么被鉴权、路由、转换、计费和记录——请求进入、选渠道、上游推理、结果返回、额度结算、日志退出。Loop Engineering 管的是循环本身。消耗大致来自重试次数 × 每轮上下文 × 推理输出 × 工具回传。优化不是把模型变弱而是从失败后原样重打大模型的 Token-rich Loop演进到加权选渠、有限重试、缓存复用、只在必要时换更大模型的 Token-efficient Loop。写在最后算力可以买模型可以换。深兰科技要拉开的差距是同一笔额度里能完成多少次有效调用。输入把信息密度做上去输出把协议和行动做稳治理让消耗变得可度量、可约束工程则让重试少空转。别再把 Token 只当成上游的计价单位而要当成可经营的数字能源。
