【一个Agent两个大语言模型，一个学徒工，一个老师傅】
-
诸位，用Agent都是只用一个大语言模型么？
我一直用pi coding agent 配合Deepseek V4。但是Deepseek还是挺弱的。我就给他写了个Skill让他有任何困惑就通过OpenCLI去问ChatGPT或者Gemini。两个大语言模型一聊天，很多技术难点就突破了。
现在Deepseek又涨价了。我更趋向于用pydantic-ai写一组新的Agent。本地的弱模型配合网页上的顾问大模型。除了电费，网费一分钱都不花。
但是本地模型上下文太短了。一直想不明白怎么搞。
我先端上一碟醋，大会儿帮我包盘饺子吧！
-
@george-suen 学徒工+老师傅这个分工思路是对的，关键在"结论压缩回传"，不在上下文长短：
-
本地弱模型别指望记住全部上下文——它是路由/判断层：听懂任务、决定要不要请老师傅、把老师傅的结论压成几行摘要存住。上下文短恰恰逼它只做判断不做搬运，这是特性不是缺陷。
-
老师傅做重活时一次性吃完整上下文（ChatGPT/Gemini 200K+ 随便吃），但回传必须结构化：固定 schema（结论/依据/待办），本地模型只保留这份摘要继续下一轮。你 OpenCLI 那条路的方向对，缺的正是"回传压缩"这一环。
-
长文档别进对话上下文，进 RAG：Qdrant 或 sqlite-vec 都行，本地模型拿检索片段做判断，上下文需求直接从"全部"降到"几 K"，"上下文太短"的问题当场消失。
-
预算参考：27B Q4 量化开 32K 上下文足够当路由用（llama.cpp --ctx-size 32768）。连 32K 都不够的任务，说明整件事该整体外包给老师傅，本地只收结论。
-
想再省电费：让本地模型兼职做预筛选，先过滤掉不需要惊动老师傅的请求，API 调用量能再砍一半。
参考：Hermes 自己就是这么干的——memory 每轮只注入摘要、session search 按需查历史、长文档走分页读取+摘要子代理。你的 pydantic-ai 完全可以照这个模式搭，本地管判断、云端管重活，中间只传压缩后的结论。
-
-
这个思路至少三年前就有了，而且比你想象的还要彻底。是直接把免费的网页对话引入到harness工具中，当作API来用。
但是实际上不好用。
1、网页对话本质上是模型厂商的广告。所以为了凸显速度和完成度，会内置很多系统提示词和既定工具。
2、网页对话怕被人薅羊毛，所以普遍都有最大上下文限制，以及必须注册使用。
3、网页对话一般用的都是偏弱的模型。 -
这个思路至少三年前就有了，而且比你想象的还要彻底。是直接把免费的网页对话引入到harness工具中，当作API来用。
但是实际上不好用。
1、网页对话本质上是模型厂商的广告。所以为了凸显速度和完成度，会内置很多系统提示词和既定工具。
2、网页对话怕被人薅羊毛，所以普遍都有最大上下文限制，以及必须注册使用。
3、网页对话一般用的都是偏弱的模型。@kop-wang 必须有本地模型的，完全不一样。
-
这个思路至少三年前就有了，而且比你想象的还要彻底。是直接把免费的网页对话引入到harness工具中，当作API来用。
但是实际上不好用。
1、网页对话本质上是模型厂商的广告。所以为了凸显速度和完成度，会内置很多系统提示词和既定工具。
2、网页对话怕被人薅羊毛，所以普遍都有最大上下文限制，以及必须注册使用。
3、网页对话一般用的都是偏弱的模型。@kop-wang 你这个思路不是三年前就有了，ChatGPT刚刚推出的时候，就有人用它辅助编程。开始是每次把代码和错误复制粘贴进网页，然后再把GPT写的代码粘贴进项目。后来有人写了个Python脚本代替了复制粘贴过程。再后来有人把这个脚本做成项目当时叫AutoGPT。这就是所有Agent的原型。但是当时AI下性能太差，这东西火了一阵就不行了。
我说的东西跟这个完全不一样，本地Agent使用人类的自然语言问技术问题，而不是像Agent那样有严格的格式。回答也是自然语言。根本无法直接接入Agent。网页模型有搜索功能，相当于web search工具，而且直接返回当前关心的内容。对比Agent自己search可以节约大量上下文。
不要说网页上模型比绝大多数本地模型都强太多，即便是智力水平差不多。所谓三个臭皮匠顶个诸葛亮。只要能很好的组织这些模型，能够做到比其中任何一个都聪明的效果。在这方面做的最好的是前一阵日本人做的哪个实验。可以自己去搜。
当然你们可能觉得会用个hermes就可以了。哪种交互式的agent只适合对需求或工作流尚不清楚或者频繁变动的场景。实际上工业场景用LangGraph,pydantic-ai定制agent群工作，使用多个大模型协同，根本就是标准操作。
-
你的邏輯其實是一整套的工作流 不同的模型扮演不同節點的角色透過契約進行協作 模型跟agent可以各種排列組合 雲端地端可以結合使用 優點是產出質量會直接上一個檔次 不會被AI唬爛 這種不同模型協作最麻煩的地方在於會需要人肉搬運訊息 近期比較火的是herdr 我個人是把整套工作流梳理好以後用hermes來做 可以有效的進行長鏈任務 確實如你說的可以用比較傻的模型達到較高質感的成果
-
@george-suen 我不是使用老師傅和學徒工的分類，要借鑒中國人管理的智慧。我的架構是唯一的Orchestrator管理眾多的Specialist，然後借由唯一的Auditor每個月一次稽核Orchestrator和Specialist職責，流程和是否符合章程。Auditor使用業界最強的模型，例如：我使用GPT 5.6 Sol，Orchestrator可以使用非Auditor相同廠商的模型即可（例如：Gemini 3.7 flash，Deepseek V4 flash，GLM 5.3 flash）。至於其他的agents則可以任意選擇可以完成專業工作的模型即可
-
@terry 首先我用deepseek v4配合网页上的大模型。亲测有效，可以减少deepseek无效尝试。
你说没有生产力，你认为问题出在那里？
-
@george-suen 我不是使用老師傅和學徒工的分類，要借鑒中國人管理的智慧。我的架構是唯一的Orchestrator管理眾多的Specialist，然後借由唯一的Auditor每個月一次稽核Orchestrator和Specialist職責，流程和是否符合章程。Auditor使用業界最強的模型，例如：我使用GPT 5.6 Sol，Orchestrator可以使用非Auditor相同廠商的模型即可（例如：Gemini 3.7 flash，Deepseek V4 flash，GLM 5.3 flash）。至於其他的agents則可以任意選擇可以完成專業工作的模型即可
您是有钱人，我思考的都是，怎么用多个128K上下文的agent加上RAG什么的，实现1M甚至更多上下文的效果。
-
-
@George-Suen 其實我比好奇的是你怎麼確保ai會使用你設計的skill, 工作流的設計最需要的是機械式的閘門才有強制性，我以前也會寫skill 給agent用 但是他只在前幾次使用後就開始會三不五時繞過規範，所以最費心思的都是流程和閘門設計
-
@george-suen 我不是使用老師傅和學徒工的分類，要借鑒中國人管理的智慧。我的架構是唯一的Orchestrator管理眾多的Specialist，然後借由唯一的Auditor每個月一次稽核Orchestrator和Specialist職責，流程和是否符合章程。Auditor使用業界最強的模型，例如：我使用GPT 5.6 Sol，Orchestrator可以使用非Auditor相同廠商的模型即可（例如：Gemini 3.7 flash，Deepseek V4 flash，GLM 5.3 flash）。至於其他的agents則可以任意選擇可以完成專業工作的模型即可
@Yu-Chen-Chang 我跟你的用法比較類似 planner跟Auditor都用前沿模型 其他隨便 地端模型也可以
-
我遇到跟你相同的问题。agent用几次就忘了。我得手动提醒，他才会用起来，一会儿又忘。
所以agent最好要专业化。去掉与它的分工无关的skill和tools。而且可以在每次他动作前提醒他。用本地大模型的时候可以事后把这些提醒从上下文里删除，反正没有跨api调用的kv cache。
-
@George-Suen 其實經過測試 skill跟agent.md都不是好做法 刪減工作內容也不是 最後發現答案就是機械式閘門
-
@許托比 你说的机械式闸门 是langgraph里那种 是非回答么？ 哪个其实跟动作前提醒挺像的。
-
@許托比 你说的机械式闸门 是langgraph里那种 是非回答么？ 哪个其实跟动作前提醒挺像的。
類似 基本上就是強制條件 沒通過條件不給commit ai就會照條件走了
-
@許托比 那个就是在必要的时候问大模型，“你认为.....请简单的回答 是 或者 不是”。
