本文來自微信公眾號(hào)： 葉小釵 ，作者：葉小釵，原文標(biāo)題：《生產(chǎn)級(jí) Agent 全景：架構(gòu)、Harness 工程、組織與人才》

上個(gè)月我這邊非常忙碌，接了個(gè)不算輕松的活：為某企業(yè)系統(tǒng)性的介紹了什么是生產(chǎn)級(jí) Agent。

懂的同學(xué)都會(huì)明白，這種面向產(chǎn)研團(tuán)隊(duì)的培訓(xùn)是很難做的，好在最后圓滿結(jié)束，也取得了不錯(cuò)的效果，整個(gè)這次培訓(xùn)前前后后進(jìn)行了 6 場(chǎng)，分別討論了框架、架構(gòu)、Skill、Tool、AI 原生組織以及 Agent 人才要求。

這些話題的設(shè)計(jì)我這邊是有深意的，背后其實(shí)圍繞著同一個(gè)問題：

Agent 進(jìn)入企業(yè)之后，究竟應(yīng)該做什么，又該怎樣做成一個(gè)可以長期運(yùn)行的生產(chǎn)系統(tǒng)？

其實(shí)現(xiàn)在很多企業(yè)都會(huì)有這種需求，因?yàn)楦嗟膱F(tuán)隊(duì)已經(jīng)可以快速做出 Agent Demo，但他們的手法都非常類似：接入一個(gè)大模型，配置幾個(gè)工具，增加知識(shí)庫，再做一個(gè)聊天界面。

可一旦進(jìn)入生產(chǎn)，很多小問題就出現(xiàn)了，如果沒有生產(chǎn)級(jí)的經(jīng)驗(yàn)，往往會(huì)摸不著頭腦，比如：

1. Agent 應(yīng)該獨(dú)立做成一個(gè)產(chǎn)品，還是放進(jìn)原有系統(tǒng)？

   
   

2. 哪些場(chǎng)景適合 Workflow，哪些場(chǎng)景適合 Agent？

   
   

3. Tool、Skill、MCP、知識(shí)庫分別承擔(dān)什么職責(zé)？

   
   

4. Agent Loop 跑起來以后，還需要補(bǔ)哪些工程能力？

   
   

5. 多 Agent 究竟解決了什么問題？

   
   

6. 企業(yè)應(yīng)該怎樣管理一個(gè)長期運(yùn)行的 Agent？

   
   

7. 產(chǎn)品經(jīng)理和工程師需要具備哪些能力？

   
   

今天，我就把之前 6 次培訓(xùn)偏理論的部分分享給大家，希望對(duì)大家有用：

Agent 在企業(yè)的定位

理解 Agent，首先要看它和現(xiàn)有軟件系統(tǒng)之間的關(guān)系。

傳統(tǒng)企業(yè)軟件承擔(dān)的核心職責(zé)，可以概括為 System of Record，記錄系統(tǒng)。

CRM 記錄客戶、線索、訂單和合同；ERP 記錄庫存、采購、銷售和財(cái)務(wù)；項(xiàng)目管理系統(tǒng)記錄需求、任務(wù)、負(fù)責(zé)人和進(jìn)度；飛書文檔看起來更加自由，每一行文字依然在記錄某類業(yè)務(wù)事實(shí)。

這些軟件幫助企業(yè)保存信息、管理對(duì)象、維護(hù)流程，并保證企業(yè)擁有一份相對(duì)可信的事實(shí)記錄。

Agent 增加了一個(gè)新的軟件層：認(rèn)知與行動(dòng)層。

用戶可以直接提交任務(wù)，例如：

幫我分析最近一個(gè)月的銷售線索，找出高價(jià)值客戶

生成跟進(jìn)建議，并把結(jié)果更新到 CRM。

Agent 接到任務(wù)后，需要完成幾件事：

1. 理解用戶的意圖；

   
   

2. 組織當(dāng)前任務(wù)需要的上下文；

   
   

3. 判斷可以使用哪些工具；

   
   

4. 調(diào)用不同系統(tǒng)完成操作；

   
   

5. 檢查執(zhí)行結(jié)果；

   
   

6. 把最終結(jié)果寫回業(yè)務(wù)系統(tǒng)。

   
   

原來需要用戶打開多個(gè)軟件、查找數(shù)據(jù)、復(fù)制信息、執(zhí)行操作?，F(xiàn)在，用戶把任務(wù)交給 Agent，由 Agent 完成中間過程。

企業(yè)軟件由此可以分成三層：用戶入口與交互層 + 認(rèn)知與行動(dòng)層 + 業(yè)務(wù)記錄層。

Agent 的價(jià)值主要取決于兩個(gè)指標(biāo)：

1. 完成了多少任務(wù)；

   
   

2. 完成的任務(wù)有多大價(jià)值。

   
   

企業(yè)最終關(guān)心的是交付結(jié)果，除此之外的聊天次數(shù)、調(diào)用工具數(shù)量、生成內(nèi)容長度，都只能算過程指標(biāo)。

為什么是 AI Coding

早期的大模型應(yīng)用主要集中在聊天、知識(shí)庫。

聊天解決信息生成問題，RAG 解決知識(shí)檢索問題，而需要完成具體任務(wù)，更多還是依賴工作流，Workflow 通過人工編排實(shí)現(xiàn)固定流程。

AI Coding 出現(xiàn)以后，模型開始在一個(gè)相對(duì)完整的環(huán)境里持續(xù)行動(dòng)，Agent 的能力也率先在編碼場(chǎng)景里得到驗(yàn)證。

Coding Agent 擁有幾個(gè)天然條件：

1. 上下文相對(duì)清晰

代碼、依賴、配置、文檔和項(xiàng)目結(jié)構(gòu)都在倉庫中。模型可以讀取文件，也可以通過搜索快速定位信息。

大量訓(xùn)練材料又來自 GitHub、技術(shù)文檔和開源項(xiàng)目，模型對(duì)代碼世界已經(jīng)比較熟悉。

2. 工具天然存在

Coding Agent 可以直接使用終端、文件系統(tǒng)、搜索命令、編譯器、測(cè)試框架和 Git。

它不需要等待每個(gè)業(yè)務(wù)系統(tǒng)重新開放接口，電腦已有的基礎(chǔ)工具就足以支持大量操作。

3. 驗(yàn)證機(jī)制比較完整

代碼是否可用，可以通過編譯、測(cè)試和運(yùn)行結(jié)果進(jìn)行驗(yàn)證。

模型寫完代碼以后可以執(zhí)行測(cè)試，發(fā)現(xiàn)問題后繼續(xù)修改，形成清晰的反饋循環(huán)。

4. 恢復(fù)成本較低

代碼有 Git，可以查看差異、保存版本和回滾修改。即使 Agent 做錯(cuò)了，也有機(jī)會(huì)恢復(fù)。

線上業(yè)務(wù)、線下服務(wù)通常缺少這種恢復(fù)能力。已經(jīng)發(fā)出的郵件、已經(jīng)提交的付款、一次錯(cuò)誤的客戶溝通，都很難直接撤銷。

綜上，Coding Agent 提供了一個(gè)適合模型持續(xù)行動(dòng)的環(huán)境：上下文清晰、工具豐富、結(jié)果可驗(yàn)證、過程可反饋、錯(cuò)誤可恢復(fù)。

Manus 早期使用 CodeAct，也延續(xù)了類似思路：把大量行動(dòng)轉(zhuǎn)換成代碼，再通過運(yùn)行環(huán)境完成任務(wù)。Codex、Claude Code 等產(chǎn)品同樣在擴(kuò)大任務(wù)范圍，希望承接更多通用工作。

因此，Coding Agent 可以看作 Agent 產(chǎn)品的早期優(yōu)勢(shì)場(chǎng)景，也是觀察通用 Agent 演化方向的重要窗口。

Workflow 還是 Agent

很多企業(yè)一看到 Agent 熱度上升，就希望所有項(xiàng)目都采用 Agent 架構(gòu)。

技術(shù)選型仍然需要回到具體業(yè)務(wù)。這里可以使用兩個(gè)維度判斷：

• 橫軸：業(yè)務(wù)知識(shí)的專業(yè)程度；

  
  

• 縱軸：工具數(shù)量、行動(dòng)次數(shù)以及循環(huán)推理次數(shù)。

  
  

固定流程適合 Workflow

如果任務(wù)步驟清楚、規(guī)則穩(wěn)定、異常較少，Workflow 通常更合適。例如：

收到表單后發(fā)送通知；

每天定時(shí)匯總數(shù)據(jù)；

根據(jù)固定字段生成報(bào)告；

按照規(guī)則完成審批流轉(zhuǎn)。

這類任務(wù)沒有太多動(dòng)態(tài)推理需求，通過流程編排可以獲得更穩(wěn)定的結(jié)果，也更容易控制成本。

專業(yè)知識(shí)場(chǎng)景需要知識(shí)工程

當(dāng)任務(wù)的行動(dòng)次數(shù)不多，業(yè)務(wù)知識(shí)比較重時(shí)，重點(diǎn)會(huì)落在知識(shí)庫、Skill、本體和知識(shí)圖譜上。

普通知識(shí)庫解決有哪些資料的問題；Skill 補(bǔ)充這些資料應(yīng)該怎樣使用；本體負(fù)責(zé)定義業(yè)務(wù)對(duì)象、屬性、關(guān)系和可執(zhí)行動(dòng)作。

知識(shí)圖譜也無需強(qiáng)制使用圖數(shù)據(jù)庫。MySQL 同樣可以保存對(duì)象、屬性、關(guān)系與 Action。關(guān)鍵在于知識(shí)是否被結(jié)構(gòu)化，模型能否在合適的任務(wù)階段取到需要的信息。

通用復(fù)雜任務(wù)適合通用 Agent

Deep Research、Coding Agent、WorkBuddy、通用辦公助手，都需要多輪行動(dòng)和持續(xù)判斷。

它們面對(duì)的業(yè)務(wù)知識(shí)相對(duì)通用，核心挑戰(zhàn)集中在任務(wù)拆解、工具選擇、上下文管理以及多輪執(zhí)行。

專業(yè)復(fù)雜任務(wù)需要業(yè)務(wù)型 Agent

金融、法律、醫(yī)療、客服等場(chǎng)景，通常同時(shí)具備專業(yè)知識(shí)和多輪行動(dòng)。

Agent 每執(zhí)行一輪，都可能需要重新注入當(dāng)前階段相關(guān)的業(yè)務(wù)規(guī)則、客戶信息、歷史記錄和權(quán)限約束。

這類系統(tǒng)的難點(diǎn)已經(jīng)超過簡單的模型調(diào)用，知識(shí)工程、流程設(shè)計(jì)、工具體系和治理機(jī)制都需要參與。

Agent 產(chǎn)品形態(tài)

Agent 的產(chǎn)品形態(tài)沒有統(tǒng)一答案，企業(yè)需要先判斷場(chǎng)景、用戶以及最終交付方式：

垂直能力可以放進(jìn)成熟產(chǎn)品

如果 Agent 主要服務(wù)已有業(yè)務(wù)，例如 CRM 中的客戶分析、項(xiàng)目系統(tǒng)中的需求拆解、客服系統(tǒng)中的回復(fù)建議，可以直接在成熟產(chǎn)品里增加一個(gè)入口。

現(xiàn)有產(chǎn)品已經(jīng)擁有用戶、數(shù)據(jù)、權(quán)限和業(yè)務(wù)流程，Agent 更容易接入真實(shí)場(chǎng)景。

通用能力可以做成獨(dú)立產(chǎn)品

如果目標(biāo)是服務(wù)多個(gè)部門，或者希望成為公司的統(tǒng)一任務(wù)入口，獨(dú)立產(chǎn)品更方便擴(kuò)展。

獨(dú)立 Agent 可以連接多個(gè)業(yè)務(wù)系統(tǒng)，建立統(tǒng)一的任務(wù)中心，同時(shí)承載權(quán)限、日志、工作區(qū)和成果管理。

Web、桌面端和 CLI 各有位置

Web 產(chǎn)品開箱即用，部署和更新也比較方便，所以早期 Agent 產(chǎn)品大量采用網(wǎng)頁形態(tài)。

桌面端可以獲得更多本地上下文，包括文件、應(yīng)用、瀏覽器狀態(tài)和操作系統(tǒng)能力。Claude Code 等產(chǎn)品讓行業(yè)重新看到本地環(huán)境的重要性。

CLI 適合開發(fā)者和專業(yè)用戶。商業(yè)化時(shí)可以通過 API Key 完成身份識(shí)別、計(jì)量和收費(fèi)。

企業(yè)場(chǎng)景很可能形成混合結(jié)構(gòu)：

桌面端負(fù)責(zé)獲取本地上下文和執(zhí)行本地操作；

云端負(fù)責(zé)連接業(yè)務(wù)系統(tǒng)、保存企業(yè)資產(chǎn)和管理權(quán)限；

SaaS 系統(tǒng)繼續(xù)保存業(yè)務(wù)事實(shí)；

Agent 負(fù)責(zé)理解任務(wù)和組織行動(dòng)。

穩(wěn)定性問題

Agent 承接的任務(wù)越重要，用戶越關(guān)心執(zhí)行過程。

一個(gè)可以穩(wěn)定交付的 Agent 產(chǎn)品，需要幫助用戶回答幾個(gè)問題：

1. 它準(zhǔn)備做什么？

   
   

2. 它正在調(diào)用哪些工具？

   
   

3. 它訪問了哪些數(shù)據(jù)？

   
   

4. 哪些操作已經(jīng)完成？

   
   

5. 哪些步驟需要人工確認(rèn)？

   
   

6. 出錯(cuò)以后能不能追蹤和恢復(fù)？

   
   

因此，產(chǎn)品設(shè)計(jì)中需要加入以下能力：

1. 工具鏈路透明

用戶應(yīng)該看到 Agent 使用了哪些工具、輸入了什么關(guān)鍵參數(shù)、得到了什么結(jié)果。

敏感信息可以隱藏，但執(zhí)行路徑需要能夠解釋。

2. Human in the Loop

高風(fēng)險(xiǎn)動(dòng)作需要人工確認(rèn)，例如：

對(duì)外發(fā)送信息；

修改關(guān)鍵業(yè)務(wù)數(shù)據(jù)；

刪除文件；

支付或退款；

發(fā)布內(nèi)容；

執(zhí)行不可逆操作。

人工確認(rèn)還可以放在計(jì)劃階段、關(guān)鍵節(jié)點(diǎn)以及最終提交階段。

3. 行為監(jiān)測(cè)和回溯

系統(tǒng)需要保存任務(wù)日志、工具調(diào)用、上下文版本、輸出結(jié)果和異常信息。

只有過程可追蹤，團(tuán)隊(duì)才能定位問題，用戶也更容易建立信任。

4. 清晰的成果區(qū)

隨著 Agent 能力提升，用戶關(guān)注的重點(diǎn)會(huì)逐漸集中在任務(wù)進(jìn)度和最終成果。

代碼編輯器關(guān)注文件和代碼；Codex 一類產(chǎn)品突出對(duì)話、工具調(diào)用和成果；Workspace 型 Agent 更強(qiáng)調(diào)目標(biāo)、任務(wù)、進(jìn)度和交付物。

未來很多 Agent 產(chǎn)品會(huì)同時(shí)提供幾種視圖：

對(duì)話視圖；

執(zhí)行過程視圖；

項(xiàng)目或 Workspace 視圖；

成果視圖。

用戶提出目標(biāo)后，可以減少對(duì)每輪對(duì)話的關(guān)注，把精力放在進(jìn)度、異常和結(jié)果上。

多 Agent 相關(guān)問題

多 Agent 要先區(qū)分產(chǎn)品設(shè)計(jì)和技術(shù)實(shí)現(xiàn)，團(tuán)隊(duì)討論多 Agent 時(shí)，產(chǎn)品經(jīng)理和工程師經(jīng)常在討論兩件不同的事情：

產(chǎn)品側(cè)關(guān)注用戶是否需要認(rèn)識(shí)多個(gè)長期存在的 Agent。例如，一個(gè)企業(yè)可以配置：

人事 Agent；

財(cái)務(wù) Agent；

寫作 Agent；

客服 Agent。

每個(gè) Agent 擁有自己的身份、工作區(qū)、歷史任務(wù)、權(quán)限和長期上下文。用戶遇到不同類型的事情，會(huì)主動(dòng)找到對(duì)應(yīng)的 Agent。

劃分依據(jù)主要是上下文和職責(zé)邊界。

公眾號(hào)、小紅書和短視頻文案通常共享大量背景資料。產(chǎn)品層沒有必要為每種渠道配置一個(gè) Agent，一個(gè)寫作 Agent 配合不同 Skill，通常已經(jīng)足夠。

技術(shù)側(cè)關(guān)注任務(wù)執(zhí)行過程中是否需要 Sub-agent 或 Agent Team。

主 Agent 可以臨時(shí)創(chuàng)建子任務(wù)，讓多個(gè) Sub-agent 并行搜索、分析或執(zhí)行，最終把結(jié)果匯總回來。

這種多 Agent 主要用于：

并行處理；

隔離上下文；

控制權(quán)限；

劃分復(fù)雜任務(wù)；

結(jié)構(gòu)化匯總結(jié)果。

用戶是否需要感知這些 Sub-agent，是另一個(gè)產(chǎn)品選擇。因此，多 Agent 設(shè)計(jì)可以先回答兩個(gè)問題：

1. 用戶是否需要長期認(rèn)識(shí)多個(gè)角色？

   
   

2. 當(dāng)前任務(wù)是否需要多個(gè)執(zhí)行單元協(xié)作？

   
   

第一個(gè)問題決定產(chǎn)品形態(tài)，第二個(gè)問題決定運(yùn)行架構(gòu)。

Agent 需要哪些技術(shù)層

一個(gè)基礎(chǔ) Agent Loop 的代碼并不復(fù)雜。

用戶提交任務(wù)，模型判斷是否調(diào)用工具，運(yùn)行環(huán)境執(zhí)行工具，再把結(jié)果交給模型。循環(huán)持續(xù)進(jìn)行，直到模型輸出最終答案。

這些東西看起來很簡單，但一上生產(chǎn)就完蛋，生產(chǎn)系統(tǒng)需要補(bǔ)齊更多能力。可以將整體架構(gòu)劃分為以下幾層：

1. Agent Loop

這是最基礎(chǔ)的循環(huán)：

用戶提出任務(wù)

→ Harness 組裝上下文

→ 模型進(jìn)行判斷

→ 返回 Tool Call 或最終結(jié)果

→ Runtime 執(zhí)行工具

→ 工具結(jié)果交回 Harness

→ Harness 重新組裝上下文

→ 模型繼續(xù)執(zhí)行

最小版本可以只完成一次 Function Calling。復(fù)雜任務(wù)需要支持多輪循環(huán)、任務(wù)終止、異常重試和狀態(tài)保存。

2. Tool 層

Tool 提供 Agent 可調(diào)用的行動(dòng)能力，包括：

1. 文件讀寫；

   
   

2. 搜索；

   
   

3. 瀏覽器操作；

   
   

4. 數(shù)據(jù)庫查詢；

   
   

5. 企業(yè)系統(tǒng) API；

   
   

6. 本地命令；

   
   

7. MCP 提供的外部工具；

   
   

8. ...

   
   

3. Context 層

Context 決定每次模型調(diào)用時(shí)，模型能夠看到什么。

常見內(nèi)容包括：

System Prompt；

用戶任務(wù)；

歷史消息；

Agent 身份；

用戶資料；

當(dāng)前計(jì)劃；

工具說明；

Skill 描述；

中間成果；

業(yè)務(wù)知識(shí)；

權(quán)限信息。

模型能力相同的情況下，Context 的質(zhì)量會(huì)直接影響 Agent 的表現(xiàn)。

4. 編排與會(huì)話管理

長任務(wù)需要保存當(dāng)前狀態(tài)，例如：

已經(jīng)完成哪些步驟；

正在處理哪個(gè)子任務(wù)；

生成了哪些文件；

哪些操作等待確認(rèn)；

失敗后應(yīng)該在哪里繼續(xù)。

會(huì)話管理還要處理歷史壓縮、上下文窗口、任務(wù)恢復(fù)和多輪協(xié)作。

5. Skill 與插件層

Skill 用來沉淀任務(wù)方法、業(yè)務(wù) Know-how、操作手冊(cè)、腳本和模板。

插件層負(fù)責(zé)讓能力可以安裝、卸載和復(fù)用。

6. 觀測(cè)與評(píng)估

生產(chǎn)系統(tǒng)需要記錄：

每輪模型調(diào)用；

Token 消耗；

工具調(diào)用；

執(zhí)行時(shí)間；

錯(cuò)誤信息；

用戶反饋；

最終成果；

任務(wù)完成率。

評(píng)估系統(tǒng)需要判斷 Agent 是否完成任務(wù)、結(jié)果是否正確、成本是否合理。

7. 任務(wù)與調(diào)度

長時(shí)間運(yùn)行的 Agent 還需要：

定時(shí)任務(wù)；

Heartbeat；

后臺(tái)隊(duì)列；

超時(shí)處理；

失敗重試；

狀態(tài)恢復(fù)；

任務(wù)通知。

8. 治理層

Agent 具有持續(xù)存在的身份和工作區(qū)。進(jìn)入企業(yè)以后，可以按照組織成員的管理方式配置：

身份；

權(quán)限；

數(shù)據(jù)范圍；

審閱機(jī)制；

行為日志；

成本額度；

風(fēng)險(xiǎn)策略；

負(fù)責(zé)人。

這部分決定了 Agent 能否進(jìn)入高價(jià)值業(yè)務(wù)。

Harness 究竟負(fù)責(zé)什么？

至此，就可以稍微深度點(diǎn)聊聊什么是 Harness 了，這個(gè)詞現(xiàn)在被提及的頻率挺高。

可以將它理解為模型外圍的一整套運(yùn)行機(jī)制：

• 最小 Harness 可能只有 ReAct Loop；

  
  

• 生產(chǎn)環(huán)境還會(huì)增加 Context、Permission、Memory、Hook、Tool、Skill、狀態(tài)管理和異常處理。

  
  

Harness 的核心任務(wù)，是在每一次模型調(diào)用前組裝合適的 Context，并在模型返回后推動(dòng)任務(wù)繼續(xù)執(zhí)行。

我們?cè)趯?shí)際調(diào)試 Agent 時(shí)發(fā)現(xiàn)，大量問題都出現(xiàn)在 Harness：

Tool 描述不清晰；

參數(shù)定義模糊；

System Prompt 內(nèi)部存在沖突；

Skill 觸發(fā)條件寫得不準(zhǔn)確；

歷史消息污染當(dāng)前判斷；

某個(gè)遺留 Hook 阻擋了操作；

工具結(jié)果過長，擠占上下文；

權(quán)限信息沒有及時(shí)更新。

模型經(jīng)常成為第一個(gè)被懷疑的對(duì)象，可順著 Trace 檢查以后，問題往往集中在上下文裝配和執(zhí)行環(huán)境：

調(diào)試生產(chǎn)級(jí) Agent，最好先查看完整鏈路：

模型實(shí)際收到了哪些消息？

工具名稱和描述是什么？

模型為什么選擇這個(gè)工具？

Runtime 實(shí)際執(zhí)行了什么？

工具返回了什么內(nèi)容？

下一輪 Context 如何組裝？

哪條規(guī)則影響了最終判斷？

有了完整 Trace，Agent 才能被持續(xù)優(yōu)化。

Tools

Tool 本身可以理解為一張可調(diào)用能力的說明書。它通常包含：

Name；

Description；

Parameters；

返回結(jié)果；

錯(cuò)誤類型。

模型讀取 Tool 的名稱、描述和參數(shù)，然后判斷是否調(diào)用。實(shí)際執(zhí)行發(fā)生在本地主機(jī)、云端 Runtime、瀏覽器或企業(yè)系統(tǒng)里。

例如，用戶詢問上海天氣。

沒有天氣工具時(shí)，模型只能依據(jù)已有知識(shí)回答，或者明確表示無法獲取實(shí)時(shí)信息。

配置天氣工具后，模型會(huì)讀取工具說明，生成類似下面的調(diào)用：

{

"city":"上海"

}

Runtime 查詢天氣服務(wù)，再把溫度、天氣狀態(tài)和時(shí)間返回給模型。模型根據(jù)工具結(jié)果生成用戶可以理解的答案。

整個(gè)過程中，模型負(fù)責(zé)推理和決策，Runtime 負(fù)責(zé)執(zhí)行。

因此，Tool 設(shè)計(jì)至少要關(guān)注四部分：

聲明

工具名稱和 Description 要準(zhǔn)確表達(dá)用途。描述模糊會(huì)直接影響模型選擇。

輸入

參數(shù)盡量結(jié)構(gòu)化，避免讓模型自由拼接復(fù)雜文本。必填項(xiàng)、格式和取值范圍都需要清楚。

執(zhí)行

執(zhí)行環(huán)境需要處理權(quán)限、超時(shí)、失敗重試、冪等性和異常。

輸出

結(jié)果應(yīng)該方便模型繼續(xù)判斷。大量無關(guān)日志、過長文本和混亂字段都會(huì)增加模型理解成本。

Tool 數(shù)量增加以后，還需要解決工具沖突、相似工具選擇、權(quán)限隔離和動(dòng)態(tài)加載問題。

正常情況下，一個(gè)團(tuán)隊(duì)后端隱藏最多的工作就是做各種 Tools 和 CLI 改造，前端工作最多的是構(gòu)建 Skills 生態(tài)：

Skills

Skill 可以看作一種能力組織格式。

一個(gè) Skill 通常是一個(gè)文件夾，核心文件為 SKILL.md，同時(shí)可以包含：

skill/

├── SKILL.md 描述任務(wù)目標(biāo)、適用場(chǎng)景和執(zhí)行步驟；

├── references/ 保存操作手冊(cè)和詳細(xì)資料；

├── scripts/ 保存可以直接執(zhí)行的腳本；

└── assets/ 保存模板、樣式和可復(fù)用物料。

Skill 沒有強(qiáng)制要求復(fù)雜協(xié)議。很多實(shí)現(xiàn)會(huì)先把 Skill 的 Name 和 Description 提供給模型，當(dāng)模型判斷當(dāng)前任務(wù)需要該能力時(shí)，再讀取完整內(nèi)容。

例如，我作為產(chǎn)品經(jīng)理，經(jīng)常需要閱讀代碼。于是可以編寫一個(gè)代碼解釋 Skill：

找到指定代碼；

增加中文塊注釋；

增加關(guān)鍵行內(nèi)注釋；

解釋主要調(diào)用鏈；

標(biāo)記需要重點(diǎn)關(guān)注的邏輯。

再比如公眾號(hào)文章抓取 Skill。它除了包含操作步驟，還可以附帶 Python 腳本。模型識(shí)別到公眾號(hào)鏈接以后，按照 Skill 說明運(yùn)行腳本，把文章轉(zhuǎn)換成 Markdown。

飛書多維表格 Skill 則可以把大量 API 操作說明放在references中。模型只在需要時(shí)讀取對(duì)應(yīng)章節(jié)，減少每次注入的上下文數(shù)量。

Tool、Skill、Pipeline 和 Agent 的區(qū)別

例如寫公眾號(hào)文章：

Tool：讀取文件、搜索資料、生成圖片、保存文檔；

Skill：選題方法、文章結(jié)構(gòu)、標(biāo)題規(guī)則、排版規(guī)范；

Pipeline：選題、資料整理、初稿、審閱、配圖、發(fā)布；

Agent：長期負(fù)責(zé)寫作任務(wù)的寫作助手。

不同的 Tool、Skill、Harness 和 Prompt 組合，會(huì)形成不同類型的 Agent。

Chatbot、Deep Research、Coding Agent 的模型可能接近，最終表現(xiàn)差異主要來自能力配置和運(yùn)行環(huán)境。

Skill 和 Pipeline 必須配合

Skill 代表能力，Pipeline 代表交付過程。

會(huì)寫標(biāo)題是一項(xiàng) Skill，每周完成三篇公眾號(hào)文章則需要完整 Pipeline。

一個(gè)內(nèi)容生產(chǎn) Pipeline 可能包含：

收集近期素材；

篩選選題；

生成文章提綱；

調(diào)用寫作 Skill；

調(diào)用審閱 Skill；

生成封面；

人工確認(rèn)；

發(fā)布并記錄數(shù)據(jù)。

Pipeline 需要明確：

當(dāng)前處于哪個(gè)階段；

每個(gè)階段由誰負(fù)責(zé)；

使用哪些 Skill 和 Tool；

輸入和輸出分別是什么；

失敗后如何處理；

哪些節(jié)點(diǎn)需要人工確認(rèn)。

企業(yè)落地 Agent 時(shí)，經(jīng)常投入大量精力編寫 Prompt，卻沒有定義任務(wù)交付管線。結(jié)果就是 Agent 單次表現(xiàn)不錯(cuò)，長期交付依然不穩(wěn)定。

生產(chǎn)級(jí) Agent

一個(gè) Agent 產(chǎn)品通常會(huì)經(jīng)歷幾個(gè)能力階段：

第一階段：能夠聊天

系統(tǒng)可以接收用戶問題，調(diào)用模型并輸出答案。

這個(gè)階段主要驗(yàn)證模型和基礎(chǔ)交互。

第二階段：能夠調(diào)用工具

Agent 可以讀取文件、查詢數(shù)據(jù)、連接業(yè)務(wù)系統(tǒng)，并根據(jù)結(jié)果繼續(xù)判斷。

此時(shí)已經(jīng)形成最小 Agent Loop。

第三階段：能夠規(guī)劃并產(chǎn)出成果

Agent 可以拆解任務(wù)、維護(hù)計(jì)劃、生成文件，并在成果區(qū)展示結(jié)果。

用戶開始把完整任務(wù)交給 Agent。

第四階段：能夠長時(shí)間運(yùn)行

系統(tǒng)加入任務(wù)隊(duì)列、Heartbeat、斷點(diǎn)恢復(fù)、重試和通知，Agent 可以處理幾分鐘、幾小時(shí)甚至更長的任務(wù)。

第五階段：能夠被治理

企業(yè)為 Agent 增加身份、權(quán)限、審閱、日志、成本控制和風(fēng)險(xiǎn)策略。

它可以接觸更加重要的數(shù)據(jù)與業(yè)務(wù)動(dòng)作。

第六階段：能夠沉淀能力

團(tuán)隊(duì)將成功經(jīng)驗(yàn)整理成 Skill、模板、工具和評(píng)測(cè)集，Agent 的能力可以復(fù)用，也可以持續(xù)迭代。

Demo 通常只覆蓋前兩個(gè)階段。生產(chǎn)系統(tǒng)的大部分工程工作集中在后面四個(gè)階段。

前面是關(guān)于 Agent 的架構(gòu)知識(shí)，那么要做這種業(yè)務(wù)需要個(gè)什么樣的團(tuán)隊(duì)呢？

AI 原生組織

相應(yīng)著，如果把視角擴(kuò)大到 AI 原生組織，可以重點(diǎn)關(guān)注四層：

Context Layer

企業(yè)需要匯聚完成任務(wù)所需的信息。

當(dāng)數(shù)據(jù)、文檔、歷史決策和業(yè)務(wù)狀態(tài)散落在不同系統(tǒng)里，Agent 很難形成完整判斷，人也需要付出大量內(nèi)部交易成本。

Context Layer 負(fù)責(zé)連接這些信息，并根據(jù)任務(wù)動(dòng)態(tài)裝配。

Pipeline Layer

Pipeline 描述任務(wù)怎樣在組織里流轉(zhuǎn)。

它需要定義角色、階段、輸入、輸出、狀態(tài)和交付標(biāo)準(zhǔn)。很多傳統(tǒng) SOP 可以在這一層被重新整理。

Skill Layer

Skill 保存組織的做事方法，包括：

專業(yè)知識(shí)； 操作手冊(cè)； 判斷規(guī)則； 分析框架； 代碼腳本； 交付模板。

員工經(jīng)驗(yàn)經(jīng)過整理以后，可以轉(zhuǎn)化為 Agent 能夠調(diào)用的能力。

Agent Governance Layer

企業(yè)把 Agent 作為持續(xù)運(yùn)行的執(zhí)行單元進(jìn)行管理，為它配置身份、權(quán)限、日志、審閱和責(zé)任邊界。

操作系統(tǒng)可以作為組織總線，人持續(xù)提供 Context，Agent 按照 Pipeline 調(diào)用 Skill 和 Tool，最后把結(jié)果寫回記錄系統(tǒng)。

這樣形成的系統(tǒng)需要具備三個(gè)特征：可運(yùn)行；可驗(yàn)證；可迭代。

業(yè)務(wù)的恢復(fù)能力

不同業(yè)務(wù)對(duì) Agent 的容錯(cuò)要求差異很大。

純線上軟件業(yè)務(wù)通常擁有日志、版本、數(shù)據(jù)庫備份和 Git，恢復(fù)能力比較強(qiáng)。線下業(yè)務(wù)、資金業(yè)務(wù)、醫(yī)療操作和對(duì)外溝通的恢復(fù)成本更高。

恢復(fù)能力較弱的業(yè)務(wù)，需要增加更多控制機(jī)制：

執(zhí)行前預(yù)覽；

分級(jí)授權(quán)；

關(guān)鍵節(jié)點(diǎn)確認(rèn)；

沙箱環(huán)境；

版本管理；

操作留痕；

人工接管；

回滾方案。

技術(shù)團(tuán)隊(duì)不能只看 Agent 能否完成任務(wù)，還要評(píng)估它做錯(cuò)以后會(huì)發(fā)生什么。

高風(fēng)險(xiǎn)場(chǎng)景可以先讓 Agent 負(fù)責(zé)分析、建議和準(zhǔn)備材料，由人完成最終提交。隨著評(píng)測(cè)數(shù)據(jù)積累，再逐漸開放部分執(zhí)行權(quán)限。

對(duì)應(yīng)著，對(duì)團(tuán)隊(duì)的要求會(huì)更多：

組織結(jié)構(gòu)會(huì)怎樣變化？

目前大部分企業(yè)的組織調(diào)整仍處于早期階段。

部分團(tuán)隊(duì)開始合并前后端崗位，產(chǎn)品經(jīng)理也會(huì)進(jìn)入代碼倉庫修改內(nèi)容，測(cè)試職能是否完全合并仍有較大差異。

很多產(chǎn)品經(jīng)理已經(jīng)使用 AI 寫代碼，同時(shí)仍然需要編寫 PRD、推動(dòng)協(xié)作和處理業(yè)務(wù)問題。

短期內(nèi)，企業(yè)更可能先改變工作邊界，再調(diào)整崗位名稱。例如：

產(chǎn)品經(jīng)理承擔(dān)更多原型和代碼工作；

工程師參與更多需求定義；

業(yè)務(wù)人員可以直接構(gòu)建簡單自動(dòng)化；

測(cè)試人員建立 Agent 評(píng)測(cè)體系；

項(xiàng)目經(jīng)理負(fù)責(zé)人與 Agent 的協(xié)作流程；

FDE 同時(shí)承擔(dān)場(chǎng)景理解、方案設(shè)計(jì)和落地交付。

組織變革不會(huì)只由工具推動(dòng)，還會(huì)受到業(yè)務(wù)風(fēng)險(xiǎn)、管理機(jī)制、評(píng)價(jià)體系和員工能力的影響：

至此，我們就走完了從架構(gòu) → 組織 → 人才的閉環(huán)了：

具體對(duì)人才的需求

招聘的起點(diǎn)通常是業(yè)務(wù)缺口。

公司先明確業(yè)務(wù)目標(biāo)，例如增長、商業(yè)化、客戶交付或平臺(tái)支撐。隨后判斷缺少什么能力，再?zèng)Q定設(shè)置哪類崗位。

一個(gè)相對(duì)完整的招聘過程包括：

明確業(yè)務(wù)目標(biāo)；

確定缺失能力；

定義崗位職責(zé)；

明確匯報(bào)關(guān)系和上下游；

確定負(fù)責(zé)的項(xiàng)目范圍；

描述候選人畫像；

通過 Sourcing 和 Mapping 尋找人才。

Sourcing 是找人，Mapping 是判斷哪些公司、部門和崗位里存在合適的人。

例如，需要建設(shè)廣告商業(yè)化系統(tǒng)，可以重點(diǎn)尋找廣告平臺(tái)、流量交易和金融相關(guān)產(chǎn)品人才。需要在復(fù)雜組織里開拓新業(yè)務(wù)，大廠加創(chuàng)業(yè)經(jīng)歷的人會(huì)比較合適：他們熟悉復(fù)雜協(xié)作，也經(jīng)歷過探索環(huán)境。

Agent 領(lǐng)域目前還沒有形成特別穩(wěn)定的產(chǎn)品和技術(shù)范式，大多數(shù)人也缺少完全匹配的項(xiàng)目經(jīng)驗(yàn)。

因此，招聘時(shí)可以重點(diǎn)觀察四個(gè)維度。

1. 基礎(chǔ)素質(zhì)

我常用四個(gè)詞：聰明；樂觀；皮實(shí)；自省。

聰明主要看學(xué)習(xí)速度；樂觀看他是否相信這件事值得投入；皮實(shí)看他經(jīng)歷失敗以后是否愿意繼續(xù)探索；自省看他能否持續(xù)復(fù)盤和成長。

2. 專業(yè)能力

級(jí)別高低通常對(duì)應(yīng)負(fù)責(zé)范圍。

P5：負(fù)責(zé)功能；

P6：負(fù)責(zé)模塊；

P7：負(fù)責(zé)產(chǎn)品；

P8：負(fù)責(zé)產(chǎn)品線；

P9：能夠自己創(chuàng)造一塊業(yè)務(wù)。

高級(jí)別人才需要具備“平地?fù)革灐钡哪芰Γ梢栽诜较虿磺逦?、資源不完整的情況下定義目標(biāo)并推動(dòng)落地。

3. 業(yè)務(wù)能力

候選人需要理解：

客戶是誰；

行業(yè)怎樣運(yùn)轉(zhuǎn)；

誰在賺錢；

商業(yè)鏈路如何分配利益；

哪些需求具有共性；

哪些需求高度定制；

產(chǎn)品如何商業(yè)化。

公司招聘產(chǎn)品和技術(shù)人員，最終仍然希望他們支持業(yè)務(wù)目標(biāo)。

4. 組織能力

候選人進(jìn)入組織以后，需要和上下游協(xié)作。

企業(yè)會(huì)關(guān)注他是否能夠推動(dòng)項(xiàng)目、處理沖突、獲得資源、管理預(yù)期，同時(shí)避免成為團(tuán)隊(duì)里的高風(fēng)險(xiǎn)項(xiàng)。

Agent 產(chǎn)品經(jīng)理和工程師應(yīng)該怎樣準(zhǔn)備？

現(xiàn)階段，完全對(duì)口的項(xiàng)目經(jīng)歷比較稀缺。候選人更需要證明自己的學(xué)習(xí)能力、場(chǎng)景理解和動(dòng)手能力。

這里Agent 產(chǎn)品經(jīng)理和Agent 工程師需要學(xué)習(xí)的重點(diǎn)就變了：

結(jié)語

寫到這里，6 次培訓(xùn)的理論板塊就結(jié)束了，如果已經(jīng)看到這里，就一定要清晰我們整體的脈絡(luò)了。

表面上看，我們討論了Agent 框架、架構(gòu)、Tool、Skill、Pipeline、多 Agent、AI 原生組織和人才要求，背后始終圍繞著一件事：企業(yè)怎樣讓 Agent 長期、穩(wěn)定地完成有價(jià)值的任務(wù)。

要做好這件事會(huì)沿著三條線匯合：

• 架構(gòu)線：Agent Loop、Harness、Tool、Skill、Context、Memory、任務(wù)調(diào)度和治理機(jī)制共同支撐長期運(yùn)行；

  
  

• 業(yè)務(wù)線：圍繞真實(shí)任務(wù)設(shè)計(jì) Pipeline，明確輸入、輸出、責(zé)任人、交付標(biāo)準(zhǔn)和異常處理；

  
  

• 組織線：重新劃分人與 Agent 的職責(zé)，調(diào)整崗位邊界、協(xié)作方式、評(píng)價(jià)體系和人才要求。

  
  

生產(chǎn)級(jí) Agent 最終會(huì)走向一個(gè)完整閉環(huán)：

先找到值得解決的業(yè)務(wù)問題，再搭建可以持續(xù)交付的系統(tǒng)，隨后把實(shí)踐經(jīng)驗(yàn)沉淀為 Tool、Skill、Pipeline 和評(píng)測(cè)集，最后形成組織可以反復(fù)使用的生產(chǎn)能力

當(dāng)然，理論框架只能幫助團(tuán)隊(duì)少走一些彎路，真正做起來具體業(yè)務(wù)，依舊會(huì)有很多坑點(diǎn)，而這些坑點(diǎn)是真正有價(jià)值的部分，比如：

團(tuán)隊(duì)為什么決定做 Agent，第一版采用了什么架構(gòu)，運(yùn)行過程中踩過哪些坑，技術(shù)方案經(jīng)歷了幾次迭代，客戶怎樣使用，哪些效果符合預(yù)期，哪些能力最后被放棄。

這些真實(shí)故事，才會(huì)讓大家看清生產(chǎn)級(jí) Agent 究竟是怎樣長出來的。