對話 Lucius 趙赫：AI 員工的本質(zhì)，是一份有 SLA 的勞動合同

Lucius 是一家做企業(yè)級 AI 員工的公司，但創(chuàng)始人趙赫不太喜歡「AI 員工」這個標(biāo)簽。他更愿意說，Lucius 做的是企業(yè)的 Context Layer，一套讓 Agent 能夠進入組織、理解現(xiàn)場、遵守邊界、持續(xù)調(diào)度任務(wù)的組織調(diào)度系統(tǒng)。

「我們不碰 Coding，因為 Coding 還是 Human in the Loop。我們做的場景一定是 AI in the Loop——AI 是主體，人來接單。」

「AI 沒辦法為最終利潤率負責(zé)。只要有人要托底，你就沒辦法實現(xiàn) 100% 自動。這不是技術(shù)問題，是制度問題。」

在他看來，真正的 AI 員工是需要簽署「勞動合同」的，只有這樣才能保證交付。

Lucius 目前服務(wù)三十余家企業(yè)客戶，春節(jié)后最快的案例是客戶看了 10 分鐘 Demo 就直接購買。團隊 12 人，CTO 來自谷歌 YouTube 機器學(xué)習(xí)組。

Lucius 的三位創(chuàng)始人

趙赫從低代碼行業(yè)轉(zhuǎn)型而來，曾在函子科技做到 40 萬用戶。他對「交付結(jié)果」有近乎執(zhí)念的堅持——Lucius 提供的每個角色都有明確 SLA，出了問題按約賠付。

以下是 Founder Park 與趙赫的對話，經(jīng)編輯整理。

產(chǎn)品官網(wǎng)：https://luciusai.com/

采訪 | 萬戶

編輯 | 夏天

??關(guān)注 Founder Park，最及時最干貨的創(chuàng)業(yè)分享

Founder Park 正在持續(xù)尋找值得被看見的 AI 團隊與項目。

我們將通過「AI 產(chǎn)品市集」、內(nèi)容報道、社群分發(fā)等方式，幫你觸達早期用戶、獲得真實反饋，以及建立關(guān)鍵連接。

如果你正在做 AI 相關(guān)的事，歡迎和我們聊聊。

01真正可以獨立做事的 AI 員工

Founder Park：簡單介紹一下團隊和個人經(jīng)歷？

趙赫：我們團隊現(xiàn)在 12 個人。部分成員來自美國大廠機器學(xué)習(xí)一線核心部門，其他工程師來自 AI 數(shù)據(jù)分析公司和客服創(chuàng)業(yè)公司。我屬于從上一代低代碼行業(yè)轉(zhuǎn)型到 AI 的。

Lucius 團隊合影

兩個合伙人。CTO 林勁超，之前在谷歌 YouTube 組做用戶異常行為檢測的機器學(xué)習(xí)組 leader。增長合伙人劉宇成，最早在 Wayfair 做用戶分析相關(guān)的機器學(xué)習(xí)，后來在國內(nèi)做了出海去孵化器 (chuhaiqu.club)。

我自己的經(jīng)歷：2017 年本科畢業(yè)后在甲骨文做了兩年售前交付工程師。當(dāng)時總結(jié)的經(jīng)驗就是要去交付結(jié)果，不是去交付工具。2019 年第一次創(chuàng)業(yè)，加入函子科技，跟著產(chǎn)品從 0 做到 40 萬用戶，做過上千個客戶的交付。所以我算是從上一時代的傳統(tǒng) SaaS、工具型 SaaS 這樣的行業(yè)轉(zhuǎn)型過來的。

2025 年 5 月份，Manus 出來前后，我當(dāng)時人在美國，跟林勁超、宇成在美國認識，大家一起聊合作做這個事情。我們都相信接下來組織協(xié)作的范式會變化，這里面會撕開很多新的普遍的需求。

當(dāng)時的起手方向就是做社區(qū)運營，跟客服比較相關(guān)。往 Context Layer 這個方向轉(zhuǎn)，是大概 2025 年底到 2026 年初，我們才把重心徹底轉(zhuǎn)到 Context 層這個方向上來。

Founder Park：當(dāng)時是怎么考慮切入這個場景的？

趙赫：最早在低代碼行業(yè)的時候就感受到，用戶操作低代碼主要涉及兩種方式：一種是自己配置工作流，第二種是自己手寫文檔。我覺得這比較反人性。當(dāng)時就在想，如果 AI 能夠很好地降低這個摩擦，真正讓用戶只用自然語言表達意圖就能構(gòu)建，那傳統(tǒng)低代碼的范式是不是就可以改變了？

當(dāng)時我覺得最適合做這個事情的場景是客服。這個場景有一個很明顯的特征：模型可以越用越聰明，能做持續(xù)學(xué)習(xí)。另外一個考慮是，我們原來在 SaaS 工具預(yù)算里廝殺，行業(yè)已經(jīng)卷得非常厲害了。看到大模型出來，第一個設(shè)想就是能不能爭取 BPO 那部分對人力的預(yù)算，做 AI labor 的交付。

2024 年 8 月份左右我離開函子。當(dāng)時關(guān)注比較多的產(chǎn)品像 Pylon 這類聚合回復(fù)平臺。本來想起手做聚合回復(fù)，但因為早期團隊人少，各種平臺兼容性問題——那時候還沒有 OpenClaw 這種 Gateway 管理多平臺的方式，所以我們決定早期先收斂到一個場景，先驗證自學(xué)習(xí)、持續(xù)學(xué)習(xí)這個東西能不能跑通。

我們當(dāng)時做過很多行業(yè)的嘗試，比如保險、傳統(tǒng)行業(yè)，還做過櫥柜平臺。平臺也很多樣，微信、郵箱、Discord、飛書，早期都試過。但最后選擇把早期精力聚焦打穿一個場景，所以起步時只做 Discord 這一個場景。

Founder Park：為什么首先選了 AI 客服這個賽道？

趙赫：過去做 AI 客服，大家只是把過去 NLP 的方式加上了 RAG。那時候客服還沒有特別深入地做成 Agent，范式還是挺像 n8n 那種傳統(tǒng)客服工作流加 NLP 檢索召回的方式。

比如 Intercom 的 Fin AI，主要是把知識庫的召回和向量化方式加上去，把答案生成從過去的固定答案匹配改成大模型召回模式。我認為這只是一個過渡狀態(tài)，不會是最終的范式。

當(dāng)時我覺得技術(shù)到了一個比較好的拐點，各種抽取模型已經(jīng)出來了，圖譜的基建也出來了，整個數(shù)據(jù)的結(jié)構(gòu)化處理和清洗已經(jīng)到了可用的狀態(tài)。

但回顧來看當(dāng)時其實有點樂觀。模型真正滿足我們想做的事情的最低要求，大概是在 Claude Opus 4.6 出來之后。因為我們大部分工作是 Context 層的收集、處理和清洗，對人的意圖識別和知識沖突冗余的去除要求比較高。早期模型在意圖識別的準(zhǔn)確率上沒那么高，幻覺率也比較高，執(zhí)行任務(wù)的成功率也不夠。

Founder Park：所以你們切的點不只是替代傳統(tǒng)客服答疑，而是更主動地把運營的事情承擔(dān)住？

趙赫：對。傳統(tǒng)客服工具的主要作用是一個管道，把客戶在隊列里排上隊，最終還是需要人去服務(wù)。我們要做的是真正意義上的 AI 員工，買回來就不需要人坐在后面。把 AI 勞動力放上去，就可以把大部分客服工作 cover 掉，最大區(qū)別就在這。

02Lucius 交付的是結(jié)果，不是提效

Founder Park：會怎么向客戶介紹 Lucius？

趙赫：如果面向終端消費者，我一般會說：一個能裝進你 IM 里的、能自主學(xué)習(xí)、能跨時間跟進事情的 AI 客服和 AI 運營。

我們今年更多強調(diào)的是幫你管理組織的 Context 層。把散落在每一次服務(wù)、每一次對話、每一次協(xié)作當(dāng)中的隱性知識或 SOP 沉淀下來，變成一個可復(fù)用的層。這個時候我們的場景就不只是客服了，客服、項目管理、數(shù)據(jù)分析都能帶起來。

Founder Park：當(dāng)時怎么判斷產(chǎn)品的 PMF？

趙赫：從三個角度來看。

第一，后面的客戶是通過看到前面客戶的案例主動找過來的。比如我們最早服務(wù)的是 Tripo、Medeo、Fellou 這些客戶，后面的 PEXO 就是因為看到前面的客戶自己主動找過來。

第二，客戶的決策周期有很大變化。早期我們跟客戶介紹的時候需要很多 Demo 和解釋價值。但從今年開始整個解釋成本比較低了，客戶看了 Demo 就能快速做決策，決策周期變得很短。

第三，老客戶出了第二條產(chǎn)品線也會繼續(xù)找我們，或者介紹身邊其他項目。在正式發(fā)布之前客戶大部分都是靠轉(zhuǎn)介紹、看案例主動過來的。我們當(dāng)時連官網(wǎng)都沒有。

Founder Park：所以其實還存在一個市場教育的階段？

趙赫：對。我覺得 Manus 是一個很好的啟蒙。「在團隊里邀請一個組織級的 AI 員工進來」這個想法的教育周期，在 OpenClaw 出來之后就降下去了。大家對什么是 AI 員工、什么是組織里的 AI Agent 有了基本了解，不用花很多時間解釋了。

OpenClaw 出來之后，我們快速擴展到三十幾個客戶，基本都是這一波帶來的。而且更重要的是，很多客戶自己嘗試過 OpenClaw 但沒有用起來。他對 Context 管理、記憶管理、分布式管理、安全性控制等知道很難之后，再看到我們的效果，接受度就很高了。

我們春節(jié)之后最快的案例，客戶聯(lián)系過來，看了 10 分鐘別的客戶在 Discord 里的案例就直接買了。

Founder Park：你們現(xiàn)在的用戶畫像是什么樣的？

趙赫：正式發(fā)布之前灰度階段面向的客戶都是初創(chuàng)公司，行業(yè)是 AI 應(yīng)用和 Web3。因為他們足夠新，對這個事的接觸程度非常高，幾乎沒有太高的教育成本。

新產(chǎn)品發(fā)出來以后，我會更面向"普通人"，比如本地的小生意，小診所、小律所這樣的生意，沒有能力 Build 的人。這些人很焦慮，很想用 AI，但用不起來。目標(biāo)用戶都是美國的，不是國內(nèi)的。

Founder Park：AI 員工和今天很多 AI Agent 產(chǎn)品的區(qū)別是什么？

趙赫：我們是交付結(jié)果的。我交付的每個角色出去都是因為我們控制好了 SLA，為這個結(jié)果負責(zé)。我們保證數(shù)據(jù)不泄露。

而能力這個東西是不確定的。你給能力強的人一個效果，給能力弱的人另一個效果。交付 Build 能力的話，「交付勞動力、交付結(jié)果」這個命題就是偽命題。你都沒有 1-2-3 的范圍，怎么交付？

這跟我們當(dāng)年低代碼最悲慘的經(jīng)歷一樣：一個項目 100 萬，我們收 2 萬，咨詢公司收 98 萬。因為能不能成功看的是售前咨詢工程師（現(xiàn)在叫 FDE）對場景有沒有理解、最終方案能不能閉環(huán)。如果是 Building Tool，主要的錢還是付給最終為結(jié)果負責(zé)的人，不是付給工具公司。

Founder Park：所以你給用戶提供的不是純粹工具，而是能交付結(jié)果的東西。

趙赫：這也是我現(xiàn)在承擔(dān)的一種壓力。投資人會問，用戶也會問：通用 AI 員工啥都能干，為啥還在干這些土場景？我不想選看起來秀肌肉的、炫酷的、好賣的場景。我知道交付增長、離錢近的東西肯定更好賣，但好賣不等于能交付。我經(jīng)常跟團隊講，低級的生意賣參數(shù)，高級的生意賣情懷。我跟客戶講的從來不是參數(shù)，我跟他說：用了我們的東西，你過節(jié)的時候就不用看手機了。

03要給 AI 員工簽一份「勞動合同」

Founder Park：選擇切入不同崗位和角色的判斷標(biāo)準(zhǔn)是什么？

趙赫：我們有一個顯式的判斷框架：生命周期長、有持續(xù)狀態(tài)更新、能閉環(huán)、Context 能被多次消費。滿足這四條的場景我們就會認真考慮。

另外還有幾個維度。第一是數(shù)據(jù)的敏感度，我們最早做客服是因為早期選的是外部數(shù)據(jù)。第二是這個場景目前客戶對出錯的容忍度。第三是整個任務(wù)的跨周期長度和閉環(huán)程度。第四是這個任務(wù)的 Scope 是不是可控。

Founder Park：這里面崗位角色的主動性會有提升變化嗎？

趙赫：肯定有。去年的 Context 層比較單薄，只有 Knowledge 這一層，就是企業(yè)的靜態(tài)知識、事實性的東西和偏好性的東西。去年沒有狀態(tài)機，不會記錄每個用戶說了什么、每個用戶當(dāng)前所處的狀態(tài)、每個任務(wù)的狀態(tài)。

今年有了狀態(tài)機之后又加了一個調(diào)度器。調(diào)度器能做的事情：第一是主動性，你可以設(shè)計一些「當(dāng)什么情形、什么狀態(tài)就執(zhí)行后續(xù)連續(xù)動作」的規(guī)則，這在去年做不了。第二是有了狀態(tài)機就可以做過程分析，比如某件事做了之前 7 天和之后 7 天的效果對比，去年也做不了。相當(dāng)于 Context 層的厚度比去年厚了很多。

Founder Park：隨著拓展的崗位不同，角色承擔(dān)的職能和被授權(quán)的權(quán)限會越來越多？

趙赫：對。對我來講 Context 有三個階段：第一階段只有外部數(shù)據(jù)；第二階段有內(nèi)部數(shù)據(jù)，更敏感的、更重要的角色；第三階段最重要的是權(quán)限和輸出格式的控制。

一個理想狀態(tài)是，比如以后你跟我做訪談，你可以不約我的時間，直接約我們公司的 Agent。我把它授權(quán)了，哪部分你能知道，你直接問 Agent。它基于我授權(quán)的范圍輸出一個 PR 給你。因為它最了解我整個公司當(dāng)前狀態(tài)，每個員工、項目、客戶的進度，所有上下文都在我們的 Context 層里。

Founder Park：如果不同人類員工之間對 AI 的表述互相矛盾，怎么處理？

趙赫：最現(xiàn)實的情況就是前腳一個人說了一個標(biāo)準(zhǔn)，后腳又一個人說了另一個標(biāo)準(zhǔn)。我們以后面的那個人為準(zhǔn)，然后后續(xù)被下一個人意識到錯了，就再糾正、再覆蓋。你問它「這個怎么來的」，它就會告訴你：最早是他說的，后來他又這么說的，現(xiàn)在是你這么說的，我就按這個干。每個知識塊都有完整的來源歷史和證據(jù)鏈。

我們之前想做一個權(quán)重機制，CEO 說的話更可信、權(quán)重更高，新來的員工權(quán)重低。后來發(fā)現(xiàn)沒有意義，CEO 說錯的比例比普通員工太多了。所以就是以時間為維度，最新為準(zhǔn)。

Founder Park：如果公司內(nèi)部知識本身混亂，AI 員工的狀態(tài)也混亂嗎？

趙赫：企業(yè)里面混亂的原因一般不是口徑不一致，張三賣 10 塊、李四賣 15 塊這種情況其實不常見。混亂更多是責(zé)任邊界不清晰。所以我們的控制就是角色邊界清晰。你讓我干不屬于我職能的事，我就說「不好意思，我沒這個角色，我沒這個職能，你讓我干這個我不干」。

學(xué)習(xí)抽取的 Context 也是有選擇性的，一定跟這個角色正相關(guān)，不是什么東西都抽進去。

Founder Park：有點像給 AI 簽了一個很明確的勞動合同。

趙赫：對。我們把 Lucius 裝進客戶工作群的時候，同事最先問的問題就是「你是誰？你能做什么？」Lucius 一定會給他說一個很清楚的邊界。如果你想讓它干額外的事，它就說「麻煩你到客戶端去開權(quán)限」。

為什么要去客戶端開？因為開權(quán)限的過程就是簽約的過程，跟勞動合同一個道理。你別想起一出是一出，要讓我干就給我簽勞動合同，我以后就干。想一出是一出讓我干，我就沒法保證交付。

Founder Park：很好奇，給 AI 太多約束會讓主動性降低嗎？

趙赫：會出現(xiàn)這個問題。一般是規(guī)則引擎里的主動性動作和底層權(quán)責(zé)之間有沖突。你告訴它是客服，主要工作是回答客戶問題、解決情緒；但同時又約束某些情況下必須閉嘴。這是典型的互斥。

目前這種問題沒有特別好的解決辦法。主要依賴基礎(chǔ)模型和提示詞工程，告訴它規(guī)則優(yōu)先于角色。比如廣告刪除會偏向更安全，模棱兩可先刪再說，但會打報告出來。踢人就更謹慎。通過被誤刪的情況來推動人去維護規(guī)則。

在更主動和更安全之間，我們選擇更安全，控制好交付的 scope。

04「完全取代」不是 Context 問題，是制度問題

Founder Park：Lucius 到今天是實習(xí)生還是正式員工？

趙赫：綜合來看，部分任務(wù)像正式員工，整體上是實習(xí)生，但趨勢明確。

我定義的標(biāo)準(zhǔn)是：第一，能獨立閉環(huán)半數(shù)以上的任務(wù)，不需要人兜底。比如退款這種情況還是個實習(xí)生。但對于使用問題咨詢，很明顯比正式員工還強。

第二，有主動性，不只是被動響應(yīng)。正式員工會主動發(fā)現(xiàn)問題、提前預(yù)警、推進事情，而不是等人問才動。這塊我們隨著 3 月上了狀態(tài)機和調(diào)度器剛開始。第三，從解決問題到消滅問題——目前還在解決問題這個層面。

3 月之后有明顯被當(dāng)成正式員工的跡象。有客戶已經(jīng)開始讓 Lucius 銳評自己產(chǎn)品最近的更新，或者問接下來更新的優(yōu)先級是什么。

Founder Park：所以你對「完全替代」這件事的判斷是漸進式的？

趙赫：系統(tǒng)是分階段的。

人一開始能接受 AI 占 30% 或 60% 的決策權(quán)重，系統(tǒng)就長那樣，該點的審批、該做的 confirm 都得有。隨著制度完善、人慢慢接受，很多東西就不用確認了。會過渡過去，但不能一口氣過。不能因為最終目標(biāo)是全自動，就跳過了信任構(gòu)建的過程。

Founder Park：你們支持的崗位都會是這樣的模式嗎？

趙赫：一定是這樣的。我們灰度測了很多崗位，不是決定做一個就突然開始，而是在客戶內(nèi)部跑灰度測試，觀察能不能實現(xiàn) AI in the Loop 的效果。如果實現(xiàn)不了，暫時不碰。

我們不碰 Coding 的原因就是：我不認為 Coding 能實現(xiàn) AI in the Loop 的效果。Coding 還是 Human in the Loop，人做主要控制，AI 做賦能，幫人實現(xiàn)架構(gòu)設(shè)計里具體要實現(xiàn)的部分。邏輯跟我們不一樣。

Founder Park：有跟 Coding 類似的你們不碰的場景嗎？

趙赫：內(nèi)容運營最難做。它需要人看了各種東西、揣摩別人心理、有能打動別人的 Brief、有所謂的 Taste 引起共鳴。這些東西大模型做得非常不好。靠量化驅(qū)動的東西在這類場景效果不好。它沒辦法成為 Plan 的制定者，有一定創(chuàng)造屬性的場景，這是特征。

Founder Park：除了隱性知識，還有哪些問題會讓"完全替代"遇到挑戰(zhàn)？

趙赫：底層原因還是上下文不足。

舉個例子：有個用戶聯(lián)系官方說網(wǎng)站訪問不了，后來從別的平臺知道他們網(wǎng)站被某個國家封了，需要掛 VPN。那個用戶花了四十幾歐買了 VPN，然后一直跟 AI 抱怨，突然 AI 就說「算了，把你的 VPN 購買的 invoice 發(fā)出來，我給你報銷」。

這種涉及到預(yù)算、折扣、輸出口徑的東西，沒辦法跳過人的權(quán)限那一環(huán)。因為成本控制的責(zé)任、最終利潤率的責(zé)任一定是有人托底的。只要這個人要托底，你就沒辦法實現(xiàn) 100% 的自動。

Founder Park：如果 Context 足夠了，這些問題能解決嗎？

趙赫：我覺得制度變了才能解決，不是技術(shù)變。跟自動駕駛一個道理，為什么允許自動駕駛？因為人類對汽車碰撞的風(fēng)險控制已經(jīng)有一套制度配套了。現(xiàn)在的 AI 就像一輛很牛的賽車，安全帶、方向盤可能有了，但保險杠、配套保險這些都還沒有。

05Context Layer 解決的是，「系統(tǒng)現(xiàn)在該怎么做」

Founder Park：最開始 Context 不夠多的時候，給用戶提供 Aha Moment 的場景是什么？

趙赫：Aha Moment 就是，它不會亂答，它拿不準(zhǔn)就來問客戶了。客戶看到的是一個很主動的、明確說「我該怎么回答」的 AI。

我們有個客戶，后來入職的員工一直以為那是個真人，「一個永遠不見面的同事在問他問題」。客戶普遍反映的 Aha Point 是「它怎么連這個都知道」，因為這些東西公司文檔里都沒有，就是不知道哪個同事順口交待的。

還有客戶說這個東西會學(xué)我說話，他覺得它會進化。管理層給我們的反饋也不是問應(yīng)答率、轉(zhuǎn)人工率這些數(shù)據(jù)，而是看到知識庫里今天有 11 個更新，過去這些碎片東西應(yīng)該就丟掉了，現(xiàn)在都在庫里躺著，管理層就已經(jīng)覺得很舒服了。

甚至有客戶問我們：能不能讓產(chǎn)品不說話，就裝在里面做 Context 抽取清洗就完了？想要的時候開個 MCP 接口、有權(quán)限控制，直接把 Context Share 給別的 Agent 用。我覺得很合理，我們產(chǎn)品不應(yīng)該只是人類友好，完全可以 Agent 友好。

Founder Park：你們會收集哪些 Context？

趙赫：內(nèi)部對 Context 收集邊界有些部分沒有確定答案。糾結(jié)的主要是交易數(shù)據(jù)和行為數(shù)據(jù)，要碰的話涉及甲方要施工，要接到他 Stripe 或應(yīng)用里。我們不太想碰，因為沒辦法一竿子捅到底。

還有代碼，有些客戶覺得代碼比文檔更好地解釋產(chǎn)品。如果我們連代碼都能讀到，故障分析會更清楚。但這是接受程度的問題。

我們現(xiàn)在是所有跟客戶的外部對話，網(wǎng)頁、郵箱、IM 都會接上去。如果比較信任就裝到內(nèi)部群，連內(nèi)部協(xié)作對話也能看見，再加上內(nèi)部文檔。

Founder Park：支撐這套 Context 層的底層技術(shù)是什么架構(gòu)？

趙赫：核心技術(shù)叫「知識引擎」。它是一個獨立服務(wù)，不依賴主 Agent 把信息推送進來，而是會主動抓取、理解和沉淀 Context。需要調(diào)用知識時，系統(tǒng)也不是簡單從向量庫里召回，而是向知識引擎里的 Agent 發(fā)起請求，由它判斷該取什么信息、如何取，以及哪些信息可信。

知識引擎的一個關(guān)鍵能力，是處理 Context 里的沖突和去重。比如同一個規(guī)則，早上有人說是 1 分鐘，下午又更新成 2 分鐘，系統(tǒng)不能把兩條矛盾信息同時保留下來，而要判斷哪一條是最新、有效的。企業(yè)里的 Context 本來就是流動的，如果不處理這些變化，AI 拿到的上下文越多，反而越容易出錯。

這套架構(gòu)和主流 Agent 最大的區(qū)別在于「解耦」。我們的 Context 層、知識引擎和調(diào)度器都是獨立的微服務(wù)，可以分別更新。主 Agent 只負責(zé)執(zhí)行，知識引擎只負責(zé)理解、推理和進化，不直接做動作。請求進來后，系統(tǒng)會先由知識引擎判斷是否需要調(diào)用 Agent；如果只是群里在慶祝，最好的處理可能就是不說話，而不是啟動完整推理鏈。

另一個關(guān)鍵點是「組合搜索」。很多產(chǎn)品把 memory 層等同于 knowledge base，什么問題都走向量召回。但其實「這個人昨天說了什么」這類問題，更適合直接查數(shù)據(jù)庫、走 SQL；只有需要模糊語義匹配時，才應(yīng)該走向量召回。知識引擎的價值就在于，它會判斷當(dāng)前任務(wù)該從哪類數(shù)據(jù)源取信息、用什么方式取，而不是每次都把整個知識庫翻一遍。

Founder Park：Context Layer 跟知識庫、Wiki、企業(yè)搜索比，到底多了什么？

趙赫：品類差異，不是程度差異。知識庫、Wiki、企業(yè)搜索解決的是「系統(tǒng)知道什么」；Context Layer 解決的是「系統(tǒng)現(xiàn)在該怎么做」。

打個比方：知識告訴你世界上有幾扇門，Context 告訴你哪扇門現(xiàn)在開著、哪扇門關(guān)著、你該走哪扇。

具體來說，Context Layer 比傳統(tǒng)知識系統(tǒng)多出四個維度。第一，從客觀知識到帶狀態(tài)的理解，不只有 Knowledge Store，還有 User Profile、Flow & Policy、Workspace State 四個 Store 協(xié)同組裝。第二，從被動檢索到主動沉淀，知識庫需要人養(yǎng)，Context Layer 在真實任務(wù)流中自己長。第三，從信息層到執(zhí)行層，Glean 幫你找到答案，Lucius 帶著完整上下文直接把事情做了。第四，從靜態(tài)知識到狀態(tài)機，沒有狀態(tài)，AI 只能描述世界；有了狀態(tài)，AI 才能參與判斷。

企業(yè)真正卡住的不是 AI 知不知道答案，而是 AI 拿到答案之后能不能在具體場景下做出正確的判斷和動作。這就是 Context 要解決的事。

Founder Park：你覺得未來個人的 Context 管理會怎么演變？

趙赫：我甚至在想我們要不要推出一個個人版產(chǎn)品。隨著 Agent 用得多了，個人就有 Context 管理的需求了。大家現(xiàn)在用 OpenAI 或者 Claude，時間長了會發(fā)現(xiàn)它模式固定。想重組你的 Context 很困難，本質(zhì)上你沒有一個 Context 組織層。

更有意思的，沒有 Agent、沒有用 Agent 的人，會去找那些長期用 Agent 的人幫他代為完成任務(wù)。比如萬老師，我想用你本地的 OpenClaw 幫我完成一個任務(wù)，因為上面有你寫文章的 taste，有你的經(jīng)驗、有你的 Context。我就愿意貢獻我的 Context 和需求給你，因為你的 Context 能幫到我。

最理想狀態(tài)應(yīng)該是：個人有 Context 管理層，組織也有 Context 管理層。組織是為了把散的東西管在一起為一個大目標(biāo)走；個人是為了管自己、更好地表達自我。

06未來的組織里，每個人都是「飛行員」

Founder Park：現(xiàn)階段你們預(yù)期的是，AI 員工完全等同于人類員工，還是與人類員工互補的關(guān)系？

趙赫：我在這個問題上糾結(jié)過。我最初的設(shè)想是完全取代人。但實際上碰到比如獎勵發(fā)放、退款這種問題，我們做不好。機器人做不好的是人能做好的 Trade-off，還有很多隱性的 Context 我們采集不到。比如這個公司發(fā)放獎勵，短期有損失但換長期收益，這種判斷我們做不了，不能替他做。

但機器能做好而人做不好的是量化。AI 可以做到第 100 次比第一次做得明顯好很多，因為它能看到前面 99 次的例子。但人記不住，沒有這個量化的辦法。

所以我現(xiàn)在想的最終畫面跟一開始不一樣了。一開始想的是：原來有個崗位是人干的，現(xiàn)在雇個 AI 100% 把人替下來。現(xiàn)在我想的是，它是一個系統(tǒng)。這個系統(tǒng)進去以后，人和 AI 的關(guān)系變成：人接單。你上班就三個任務(wù)，這三個任務(wù)會告訴你明確的上文 Context、需要做什么。丟給人的是 AI 跟物理世界連接不了的東西。這種系統(tǒng)整體是反脆弱的，把 Trade-off 收到系統(tǒng)里面了。

Founder Park：你們所說的 AI in the Loop 和 Human in the Loop 有什么核心區(qū)別？在你看來，最終組織形態(tài)會長什么樣？

趙赫：我覺得最終組織形態(tài)就是，大部分白領(lǐng)變成監(jiān)督者。每個人都是飛行員，飛機越來越自動化，飛行員從「駕駛飛機」變成「監(jiān)控系統(tǒng)、處理異常」。

我認為好的 AI 系統(tǒng)的最終效果應(yīng)該就是這樣。人的要求會變得兩極分化：要么就是個基礎(chǔ)人類，能接 AI 給我的單、能處理物理事件；要么就是管理者，決定什么樣的生意要做、賦予東西意義。

在這種系統(tǒng)里，人的培訓(xùn)成本就很低。任務(wù)都是 AI 給你明確上下文之后派出來的，甚至不需要勞動合同，我就是臨時過來做 10 個單子然后走了。而且一旦有系統(tǒng)，你做過的單子都有評價體系在里面，你不好好做以后接不到這種單子。

AI 能夠把服務(wù)成本降到極低，實現(xiàn)真正的個性化。比如給本地餐廳推銷，你可以直接用 AI 幫他量身定制好菜單發(fā)過去，根本不用等他來注冊，直接把結(jié)果給他說這已經(jīng)是你公司的員工了你要不要？400 次免費，用好了你就付錢。這在以前根本不可能。

但它是分階段的，沒有辦法一竿子捅到底。隨著制度完善和人的接受度提升，系統(tǒng)里很多東西會逐步變成次拋的，人要確認的東西越來越少。

07每個人都能 Build 自己的東西」是不現(xiàn)實的

Founder Park：定價策略是怎么考慮的？

趙赫：Lucius 推出了免費版本，助力早期社區(qū)做好出海用戶運營。收費按 Action 計價，不管是知識清洗還是 Context 清洗，我們也算成 Action。

三個版本：第一個完全免費，400 個 Action 以下隨便用；最便宜的是 199 美金/月；最貴的目前是 499 美金/月，3000 個 Action，可以 0.15 美金一個 Action 進行增購。

定價是平衡了美國當(dāng)?shù)馗鞣N BPO 的價格設(shè)計的。之后會出現(xiàn) 1500、2000 這種價格的角色，必須有更高級角色出現(xiàn)時才設(shè)置。

買傳統(tǒng)客服可能需要自己配工作流、手寫文檔上傳才能開始用。買我們的客服什么都不用干，直接裝進去，安裝即開始，零起手配置。

Founder Park：如果通縮持續(xù)、人力價格被壓下來，AI 員工的定價空間會不會被人力價格倒掛？

趙赫：會的。所以要加快向 Context Layer 靠近。如果只賣「替人干活」，人便宜了你就得跟著便宜。但如果賣的是「組織的 Context 積累」，這個東西越用越厚，換不掉，那定價邏輯就不一樣了。

Founder Park：交付結(jié)果的產(chǎn)品和增強人類能力的工具，未來誰會更強？

趙赫：最后會分層。目前 AI 服務(wù)的 Builder 大概幾千萬，在能享受 AI 生產(chǎn)力提升的群體里面是非常少的一部分人。技術(shù)跑得很快，但普通人追不上來，他有自己的生意，沒時間去 Build。所以大部分人只能買結(jié)果。

最終的狀態(tài)應(yīng)該是：通用性的東西專門服務(wù)有能力構(gòu)建的 Builder；能交付結(jié)果的服務(wù)沒有能力構(gòu)建的大多數(shù)人。

用上一時代的例子：我們是做低代碼的，低代碼理論上學(xué)會了什么都能 Build。但這樣的產(chǎn)品不影響有贊、微盟上市，也不影響 Shopify、Wix 占大份額。Builder 型工具一直沒有占特別大的份額。

Founder Park：這么說的話，"每個人都能 Build 自己的東西"這個場景是不是太理想化了？

趙赫：太理想。之前有人問我 AI Coding 這么牛了，是不是所有應(yīng)用都次拋，需要什么就現(xiàn)場生成？這個前提是 AI 有足夠多的常識能輸出最優(yōu)解。但最優(yōu)解是 It Depends，要基于你此時此刻的狀態(tài)給你一個最優(yōu)解。

最優(yōu)解沒有通用解，最優(yōu)解和唯一解不是一回事。

而且普通人有沒有成本做試錯？讓 AI Build 一個東西，一遍不行兩遍不行十遍不行，有這個時間成本和機會成本嗎？只要進入盈利性的生意，對時間成本容忍度極低。To B 的世界就是：買過來就必須行。

但 To C 不一樣。To C 主要是好玩，Build 的過程就是滿足欲望。當(dāng)年函子有統(tǒng)計數(shù)據(jù)，超大比例的應(yīng)用搭建出來沒有任何實際意義，搭建的過程就是它的意義。大學(xué)生是 AI Coding 的主流群體，當(dāng)年低代碼時就是。做最多的項目是二手交易商城和表白墻，到了 AI Coding 還是這兩個。有意義嗎？沒有。但他很快樂，為快樂付錢就是意義。

有人跟我說「我不玩游戲了，直接用 AI Coding，每天 Build 東西比玩游戲快樂多了」。跟沙盒游戲、我的世界一樣的探索感。但最后發(fā)現(xiàn)投到生產(chǎn)里不能用，還是去買了產(chǎn)品。很多人嘴上罵產(chǎn)品簡單，Manus 剛出來大家都說"這東西好簡單我自己也能做"，但即便做成那樣子也是很困難的，里面有大量經(jīng)驗和 Prior。

08Harness 是核心本體和真正壁壘

Founder Park：技術(shù)上來看，你們跟 OpenClaw 這類開源框架的本質(zhì)區(qū)別在哪？

趙赫：OpenClaw 解決了一個很重要的問題——讓 AI 能動手。它證明了 Agent 可以連接工具、跑多步驟任務(wù)、調(diào)用 API。但企業(yè)場景里有三件事它解決不了。

第一，多租戶隔離。OpenClaw 是「一個人用一個 Agent」的架構(gòu)。但我們要同時服務(wù)幾十個客戶，每個客戶有自己的知識庫、規(guī)則、用戶畫像，數(shù)據(jù)必須完全隔離。這不是在外面包一層就能解決的，要求從數(shù)據(jù)模型到上下文組裝到權(quán)限控制，全鏈路都按租戶隔離。

第二，企業(yè)級治理。OpenClaw 的安全策略寫在 prompt 里，意味著用戶可以通過 prompt injection 繞過去。我們的安全底線是寫在代碼里的，模型根本看不到那層邏輯，不存在繞過的可能。另外企業(yè)要的是「什么角色能做什么事、什么情況必須轉(zhuǎn)人工、誰來負責(zé)」，這一整套治理框架，開源框架完全沒有。

第三，被動沉淀 Context 的能力。開源框架的記憶基本是個人級的，記住你喜歡什么格式、上次說了什么。但企業(yè)需要的是組織級的 Context 積累：知識盲區(qū)自動追蹤、用戶畫像跨會話沉淀、處理模式越用越厚。這不是一個記憶模塊能解決的，它需要知識引擎、用戶畫像系統(tǒng)、狀態(tài)機、反饋環(huán)路整個閉環(huán)跑起來。

一句話總結(jié)：OpenClaw 給了你一個很強的發(fā)動機。但我們需要造的是一輛能在企業(yè)高速公路上合規(guī)行駛的車，有安全帶、有保險、有導(dǎo)航、還得記得路。發(fā)動機只是其中一個部件，而且它還是可以換的。真正不可替代的是外面那一整套 Harness。

Founder Park：你們是怎么搭建 Harness 的？

趙赫：結(jié)合我們的實踐，Harness 至少包含四層?xùn)|西。

第一，上下文組裝，誰在問、問的是什么、這個人之前經(jīng)歷了什么、公司的規(guī)矩是什么，全靠 Harness 在調(diào)用 LLM 之前組裝好塞給它。

第二，行為約束，哪些話絕對不能說、哪些情況必須轉(zhuǎn)人工，這一層不是靠 prompt 實現(xiàn)的，是代碼級強制執(zhí)行的。

第三，狀態(tài)管理和任務(wù)調(diào)度，模型是無狀態(tài)的，但企業(yè)場景里的任務(wù)有連續(xù)性，Harness 負責(zé)維護這些狀態(tài)。

第四，可觀測性和評估，模型做了什么決策、調(diào)了哪些工具、回復(fù)質(zhì)量怎么樣，全要被記錄，可追溯、可審計、可改進。

對 Lucius 來說，Harness 不是一個附加功能，它就是我們產(chǎn)品的核心本體。LLM 是可以換的，Claude 換 GPT，用戶無感，但 Harness 換不了，因為里面沉淀的是對企業(yè)場景的理解、對用戶行為的建模、對治理邊界的定義。這些才是真正的壁壘。

09最怕的不是跑不夠快，而是跑錯了

Founder Park：團隊的壁壘是什么？

趙赫：最核心是工程能力。怎么保證在復(fù)雜的分布式交付情況下的交付質(zhì)量。競品想學(xué)的話需要很長時間，領(lǐng)頭的人底子必須有大型系統(tǒng) Infra 構(gòu)建經(jīng)驗。需求誰都看見了，但沒人構(gòu)建，本質(zhì)上是大型系統(tǒng)構(gòu)建的工程管理難度不低。

另外一個軟性的東西是「示能」，最近紅杉有個分享提到的概念叫「示能」（Affordance），就是做出來的東西別人一看就知道干什么的、怎么用。產(chǎn)品設(shè)計上能不能讓人一看就知道怎么用，這是一種很難復(fù)制的能力。

最傳統(tǒng)的說法是數(shù)據(jù)和品牌，只有這兩個能跨周期。采集數(shù)據(jù)、消費數(shù)據(jù)的閉環(huán)必須順暢，市占率推動速度要快。

Founder Park：如果 Discord 或 Slack 官方下場，直接內(nèi)置類似 Lucius 的 AI 員工，你們怎么辦？

趙赫：Lucius 解決的是信息散落的問題，它要做我這個層，也得支持多平臺。聚水潭不害怕電商自己的 ERP，它存在本身就是因為有多平臺和多店鋪以及多倉庫的管理，平臺方的 ERP 很難撼動它的位置。單一平臺做自己的 AI 也一樣，你的 Context 不可能只在一個平臺上。

Founder Park：會擔(dān)心你們在模型公司的主干道上嗎？

趙赫：模型現(xiàn)在做的記憶層主要管理用戶跟 AI 之間的 Conversation，不是業(yè)務(wù)流轉(zhuǎn)中的狀態(tài)數(shù)據(jù)。模型確實在轉(zhuǎn)向 To B，OpenAI 和 Anthropic 跟 PE 公司成立合資公司，但走的是 FDE 路線、塔尖的 KA 客戶。

用朱嘯虎的話說：這種臟活他們不愿意做，影響估值。從最底層踩碎片做清洗，這個活又臟又累。模型廠合資搞 FDE，本質(zhì)也是為了擴大 API 的銷售量。Context 層能幫模型進入之前進不去的最后一公里場景，我們可以幫模型更下沉。

Founder Park：你覺得你們是這個賽道的引領(lǐng)者嗎？

趙赫：在 Context 層的沉淀和清洗這一塊當(dāng)下絕對算。但引領(lǐng)者能保持的周期越來越短了，一旦我們 PR 了，出現(xiàn)類似產(chǎn)品的周期就可以倒計時了。

最怕的不是跑不夠快，而是跑錯了，一步踩空三個月身位就沒了。下一個角色選錯了、Context 方向不對，市占率就被趕超。

正確的邏輯是：把 Context Layer 采集和消費做好的最小場景，但夠普及、速度快。切進來拿到 Context 了，可以慢慢加功能。先把信任構(gòu)建起來，他信你，才敢把 Context 放你這。

Founder Park：你今年會焦慮什么？

趙赫：團隊跑的速度上有些焦慮。最焦慮的問題是消費者期待過高，市場被各種 AI 產(chǎn)品挑動得很高，有人認為買個 AI 員工下個月就可以裁員了，這種不正確的期待需要有教育成本。

團隊速度方面：我們推出來的已經(jīng)是內(nèi)部第四版。每次版本切換做遷移很頭疼，測試工程量幾何倍增長，系統(tǒng)一變測過的都要重新測。犯過的最大的錯就是沒更早做 Test Infra。

另外一個點是現(xiàn)在招來的工程師比較浮躁，AI Coding 賦予了很大能力后想做大東西，讓他蹲下來打磨工程化的東西就沒耐心。每次看到 OpenClaw 或 Hermes 出來，團隊也會有情緒，擔(dān)心被吃掉市場。但我個人戰(zhàn)略定位比較穩(wěn)，不會跳來跳去。

還有代碼 Review 比以前更難，代碼產(chǎn)出快了，但工程化組合出結(jié)果的速度沒有預(yù)想那么快。提交上來的 PR 還是要人審，一個功能四五小時做完，測試加推上去可能要兩周。

Founder Park：如果兩年后這個事沒做成，你覺得是什么原因？

趙赫：應(yīng)該是市占率滲透速度不夠快。商業(yè)化增長速度不夠快。

轉(zhuǎn)載原創(chuàng)文章請?zhí)砑游⑿牛篺ounderparker