博客
探索 AI 技术的前沿动态与深度洞察
Agent 一多，单模型这条路就开始有点拧了
前面很多人聊 Agent，重点还放在“能不能让它自己干活”。
为什么 Agent 越多，越容易走到多模型分工这一步？
前面很多人聊多模型，语气还像是在讨论一种“更完整的架构选择”。
Agent 多模型协同怎么做？工作流一变长，单模型就开始不太够用
Agent 多模型协同，最近几乎成了所有 Agent 落地团队绕不开的话题。
Agent 工作流里，模型分工为什么会越来越明显
前两年大家聊多模型，很多时候还停留在一个比较抽象的层面：是不是要多接几家模型，出了问题能不能切，价格能不能压一点。
Agent 热起来之后，多模型需求也会跟着放大
最近 Agent 的热度上来之后，一个连带变化也越来越明显：多模型这件事，开始从“技术备选项”慢慢变成“系统迟早要补的一层”。
Agent 编排里怎么划分模型职责：从 Planner、Worker 到 Verifier
Agent 这波真正落地之后，“多模型”越来越不像一种额外能力。
一个 Agent 工作流里配几类模型更合适？很多时候先把这几层分开就够了
Agent 火起来之后，很多团队很快就会问一个问题：既然工作流已经开始变长，那到底要配几类模型才算合理？
Agent 系统为什么会慢慢走到多模型？很多团队都是做到后面才发现这一点
一开始做 Agent 时，很多团队的直觉都差不多：先找一个强模型，把链路跑起来，后面再说。
Agent 一旦跑起来，多模型这件事大多绕不过去
很多团队前面做 Agent，还会把注意力放在“能不能让它自己跑起来”。
Agent 工作流里的模型怎么选？先把规划、执行、校验这三层拆开
Agent 真开始落地之后，模型选型会比普通对话系统复杂很多。
Agent 系统为什么会逼出更清晰的模型分工？因为这几层开始分开了
Agent 进入正式业务之后，模型选型会比普通对话系统更快走到“结构问题”。
企业 Prompt 缓存怎么做？想降低多模型调用成本，往往要先拆背景层
企业一旦开始正式用大模型，缓存几乎迟早都会被提上来。因为只要请求量起来，重复发送的上下文和背景内容就会慢慢变成一笔很实在的成本。
我做了一圈 Prompt 缓存后才发现，很多人其实省错了地方
我一开始看大模型缓存，也很容易把注意力放在 prompt 本身。
Prompt 缓存做了为什么还是没省钱？很多团队问题都出在背景层
缓存这件事，听起来很像一个天然正确的动作。既然模型调用贵，那把 prompt 缓起来，不就应该能把钱省下来吗？
Prompt 缓存怎么设计？先拆稳定背景，很多系统这样更容易省 token
Prompt 缓存怎么设计？很多团队第一反应都是把整段 prompt 缓起来，但真跑到业务里，命中率往往没有想象中高。