Lucius 是一家做企業級 AI 員工的公司，但創始人趙赫不太喜歡「AI 員工」這個標簽。他更愿意說，Lucius 做的是企業的 Context Layer，一套讓 Agent 能夠進入組織、理解現場、遵守邊界、持續調度任務的組織調度系統。

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

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

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

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

Lucius 的三位創始人

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

以下是 Founder Park 與趙赫的對話，經編輯整理。

產品官網：https://luciusai.com/

采訪 | 萬戶

編輯 | 夏天

??關注 Founder Park，最及時最干貨的創業分享

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

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

如果你正在做 AI 相關的事，歡迎和我們聊聊。

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

Founder Park：簡單介紹一下團隊和個人經歷？

趙赫：我們團隊現在 12 個人。部分成員來自美國大廠機器學習一線核心部門，其他工程師來自 AI 數據分析公司和客服創業公司。我屬于從上一代低代碼行業轉型到 AI 的。

Lucius 團隊合影

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

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

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

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

Founder Park：當時是怎么考慮切入這個場景的？

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

當時我覺得最適合做這個事情的場景是客服。這個場景有一個很明顯的特征：模型可以越用越聰明，能做持續學習。另外一個考慮是，我們原來在 SaaS 工具預算里廝殺，行業已經卷得非常厲害了?？吹酱竽Ｐ统鰜恚谝粋€設想就是能不能爭取 BPO 那部分對人力的預算，做 AI labor 的交付。

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

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

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

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

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

當時我覺得技術到了一個比較好的拐點，各種抽取模型已經出來了，圖譜的基建也出來了，整個數據的結構化處理和清洗已經到了可用的狀態。

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

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

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

02Lucius 交付的是結果，不是提效

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

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

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

Founder Park：當時怎么判斷產品的 PMF？

趙赫：從三個角度來看。

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

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

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

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

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

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

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

Founder Park：你們現在的用戶畫像是什么樣的？

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

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

Founder Park：AI 員工和今天很多 AI Agent 產品的區別是什么？

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

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

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

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

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

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

Founder Park：選擇切入不同崗位和角色的判斷標準是什么？

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

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

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

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

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

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

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

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

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

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

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

Founder Park：如果公司內部知識本身混亂，AI 員工的狀態也混亂嗎？

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

學習抽取的 Context 也是有選擇性的，一定跟這個角色正相關，不是什么東西都抽進去。

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

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

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

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

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

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

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

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

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

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

我定義的標準是：第一，能獨立閉環半數以上的任務，不需要人兜底。比如退款這種情況還是個實習生。但對于使用問題咨詢，很明顯比正式員工還強。

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

3 月之后有明顯被當成正式員工的跡象。有客戶已經開始讓 Lucius 銳評自己產品最近的更新，或者問接下來更新的優先級是什么。

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

趙赫：系統是分階段的。

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

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

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

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

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

趙赫：內容運營最難做。它需要人看了各種東西、揣摩別人心理、有能打動別人的 Brief、有所謂的 Taste 引起共鳴。這些東西大模型做得非常不好?？苛炕寗拥臇|西在這類場景效果不好。它沒辦法成為 Plan 的制定者，有一定創造屬性的場景，這是特征。

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

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

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

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

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

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

05Context Layer 解決的是，「系統現在該怎么做」

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

趙赫：Aha Moment 就是，它不會亂答，它拿不準就來問客戶了?？蛻艨吹降氖且粋€很主動的、明確說「我該怎么回答」的 AI。

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

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

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

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

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

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

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

Founder Park：支撐這套 Context 層的底層技術是什么架構？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Founder Park：現階段你們預期的是，AI 員工完全等同于人類員工，還是與人類員工互補的關系？

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

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

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

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

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

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

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

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

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

07每個人都能 Build 自己的東西」是不現實的

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

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

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

定價是平衡了美國當地各種 BPO 的價格設計的。之后會出現 1500、2000 這種價格的角色，必須有更高級角色出現時才設置。

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

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

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

Founder Park：交付結果的產品和增強人類能力的工具，未來誰會更強？

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

最終的狀態應該是：通用性的東西專門服務有能力構建的 Builder；能交付結果的服務沒有能力構建的大多數人。

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

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

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

最優解沒有通用解，最優解和唯一解不是一回事。

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

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

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

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

Founder Park：技術上來看，你們跟 OpenClaw 這類開源框架的本質區別在哪？

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

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

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

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

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

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

趙赫：結合我們的實踐，Harness 至少包含四層東西。

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

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

第三，狀態管理和任務調度，模型是無狀態的，但企業場景里的任務有連續性，Harness 負責維護這些狀態。

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

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

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

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

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

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

最傳統的說法是數據和品牌，只有這兩個能跨周期。采集數據、消費數據的閉環必須順暢，市占率推動速度要快。

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

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

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

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

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

Founder Park：你覺得你們是這個賽道的引領者嗎？

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

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

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

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

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

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

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

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

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

趙赫：應該是市占率滲透速度不夠快。商業化增長速度不夠快。

轉載原創文章請添加微信：founderparker