【一个Agent两个大语言模型，一个学徒工，一个老师傅】
-
这个思路至少三年前就有了，而且比你想象的还要彻底。是直接把免费的网页对话引入到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就會照條件走了
-
@許托比 那个就是在必要的时候问大模型，“你认为.....请简单的回答 是 或者 不是”。
-
@George-Suen 你這樣不太行 必須先定義什麼是必要的時候 這樣閘門才有意義且可以自動 例如資安問題必須通過前沿模型檢核並附上證據 ai在通過閘門的時候沒幹這事就會被擋下來 然後乖乖去做 不需要按是或否
@許托比 我说的是 这种东西，它本来就在工作流图里。https://reference.langchain.com/python/langgraph/graph/state/StateGraph/add_conditional_edges
你举得资安的例子，我完全没概念，从未接触过。 -
@許托比 我说的是 这种东西，它本来就在工作流图里。https://reference.langchain.com/python/langgraph/graph/state/StateGraph/add_conditional_edges
你举得资安的例子，我完全没概念，从未接触过。 -
我觉得本地模型最大的短板是知识面不够，大局观不够。
所以只让agent在项目设计和遇到难题时才去与线上模型讨论，这样应该能省些上下文，并且要限制轮数。
还有个方案就是线上模型的回答不要直接喂给agent，因为线上模型经常长篇大论，中间可以加一个小模型总结摘要以后再喂给agent。
这两个也可以综合起来用。@neo 甚合我意
