【一个Agent两个大语言模型，一个学徒工，一个老师傅】
-
-
@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 甚合我意
-
我遇到跟你相同的问题。agent用几次就忘了。我得手动提醒，他才会用起来，一会儿又忘。
所以agent最好要专业化。去掉与它的分工无关的skill和tools。而且可以在每次他动作前提醒他。用本地大模型的时候可以事后把这些提醒从上下文里删除，反正没有跨api调用的kv cache。
-
@George-Suen 开源专案 archon 可能可以帮到你
你想要的比较像是一个 WORKFLOW上下文不行 其实 是因为 pi 本身 compact 没有很强 你要试试看 pi-blackhole 插件
或是用omp.sh 可以解决上下文问题。。。
@Botio-Kuo 我想的是把信息分给多个agent维护，再有一个agent维护信息的目录。工作agent只维护当前问题的上下文。需要了解历史问题的时候去问他们。
-
@Botio-Kuo 我想的是把信息分给多个agent维护，再有一个agent维护信息的目录。工作agent只维护当前问题的上下文。需要了解历史问题的时候去问他们。
-
哥兒們 玩ai永遠記住一個原則 非機械式的規範不可能限制ai ，prompt 下的再好，agent.md或skill寫得再強制 ，ai就是能夠繞過去 ，血的教訓。然後其實地端模型請教前沿模型的做法有點繞路，地端模型是拿來幹活，他不需要在過程中請教，他需要的是一開始有明確的規劃和事後有嚴格審查，所以你的老師傅的位置不應該在徒弟旁邊手把手，而是一開始說清楚叫他幹嘛然後他做完後嚴格的審核他
我信你说的话。
但是咱俩用Agent的场景完全不同。我做的东西全凭自己的兴趣，都带有探索性。我做的上一个项目，一开始也是用AI计划，最后发现那条路完全走不通，一直改一直改。好在最后结果我很满意。而且我也不太在乎AI犯错，反正都是我在尝试的事情。
-
@George-Suen 喔 。。。 那你要用 BUZZ 可以多个 AGENT 共用一段上下文。。。
或是你就用 firstmate 等 派工SKILL 就行， 说实在的 很多方式都能达到目的
你也可以自己写一个 SKILL ， 清楚表明要分派哪些内容给什么 subagent 並且 他只能看哪些内容 边界定义好 -
Gemini 这个老师傅还能服役？
它的老年痴呆有救了？ -
您是有钱人，我思考的都是，怎么用多个128K上下文的agent加上RAG什么的，实现1M甚至更多上下文的效果。
George-Suen 以前Deepseek是白菜價的時候，可以放任放任Deepseek自己不斷地試錯，畢竟白菜價要什麼自行車？但是當尖峰時刻Cache hit大漲價以後（尖峰五倍），這台自行車就必須是我要的山地車還是競速車。所以，如果可以利用比較規矩的模型來指揮Deepseek V4 flash做事，事實上可以省不少錢。
