在許多人工智慧項目中，最常見的「技術債務」類型如下：
它一開始是一個提示，
後來又增加了幾行規則，
然後填入工具調用、條件分支、異常處理
最終成為了無人敢改的「超級提示」。
Wshobson/掮客 該項目關注問題本身：
當人工智慧不再只是聊天而是參與實際任務時，我們應該如何「設計」人工智慧。
1.這個項目的核心目標是什麼？
一句話總結：
在軟體工程中定義、組織和組合人工智慧代理，而不是堆積提示。
它不嘗試：
- 交付開箱即用的人工智慧產品
- 展示模特有多強大
相反，它解決了一個更根本的問題：
代理應該如何「寫入代碼」，而不是「寫入文本」。
2.為什麼工程中提示不夠？
在原型階段，提示工作良好;
但在工程階段，它存在幾個致命問題：
1不維護
- 規則越多，提示時間越長
- 改變一個地方可能會影響整體行為
- 沒有明確的「責任邊界」
2.無法再次使用
- 提示綁定到任務
- 很難提取「分析能力」和「驗證能力」單獨重用
3.協作是不可能的
- 所有任務都交給同一個模型
- 推理、執行和驗證是混合的
劑 該項目的立場很明確：
這些不是模式問題，而是結構性問題。
3. Agent在這個項目中意味著什麼？
Wshobson/掮客 在設計中：
代理髮送提示
代理=角色+責任+行為約束
代理通常具有：
- 明確的角色定位（只做一類事情）
- 穩定的投入/產出預期
- 固定的工作方式，而不是「只是玩」
這與後台的概念非常相似：
| 後端系統 | AI系統 |
|---|---|
| 服務 | 劑 |
| 控制員職責 | 代理人角色 |
| API輸入和輸出 | 代理I/O |
| 調用鏈 | 劑管道 |
4.多智能體，而不是「通用AI」
該項目最重要的工程想法之一是：
不要試圖用一個代理完成所有事情。
相反，它被分為多個具有單一職責的代理，例如：
- 分析代理：僅負責理解問題和分解任務
- 執行代理：負責特定的構建或操作
- 驗證代理：它只負責檢查、糾正錯誤和約束輸出
從工程方面來說，這帶來了幾個明顯的好處：
更穩定
每個主體的行為範圍是可控的。
易於調試
你可以清楚地知道：
哪一步出了問題，而不是「今天模型狀態不好」。
更容易擴展
當添加新要求時，通常是以下內容：
- 添加代理
- 或更換代理人
而不是重寫整個提示。
5.這不是演示，而是「結構性演示」
Wshobson/掮客 代碼本身並不複雜，
但它的價值不在於「實施技巧」，而在於 結構選擇:
- 代理人都是一流公民
- 合作關係明確
- 行為可以結合
這使得它更像是：
代理系統的最低可行架構
而不是教授玩具例子。
6.從工程角度進行評價
從工程角度來看，我的判斷是：
這是一個「代碼並不複雜，但面向性非常好」的項目。
它並不能解決所有問題，但至少澄清了一件事：
當人工智慧進入工程領域時，它必須像軟體模塊一樣設計，而不是建立在靈感之上。
如果說Promise是「腳本時代」，
這種代理結構顯然正在走向「系統時代」。
結語
Wshobson/掮客 它不會直接提高您的模型能力。
但它會 大大提高人工智慧系統構建量的上限.
對於那些真正想使用人工智慧作為工程組件的人來說，
這種項目值得反覆研究。
Github：https://github.com/wshobson/agents
管材：