对话 Lucius 赵赫：AI 员工的本质，是一份有 SLA 的劳动合同

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/

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 掉，最大区别就在这。

02 

Lucius 交付的是结果，

不是提效

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 块这种情况其实不常见。混乱更多是责任边界不清晰。所以我们的控制就是角色边界清晰。你让我干不属于我职能的事，我就说「不好意思，我没这个角色，我没这个职能，你让我干这个我不干」。

学习抽取的 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 足够了，这些问题能解决吗？

赵赫：我觉得制度变了才能解决，不是技术变。跟自动驾驶一个道理，为什么允许自动驾驶？因为人类对汽车碰撞的风险控制已经有一套制度配套了。现在的 AI 就像一辆很牛的赛车，安全带、方向盘可能有了，但保险杠、配套保险这些都还没有。

05

Context 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% 把人替下来。现在我想的是，它是一个系统。这个系统进去以后，人和 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。

08 

Harness 是核心本体和真正壁垒

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：如果两年后这个事没做成，你觉得是什么原因？

赵赫：应该是市占率渗透速度不够快。商业化增长速度不够快。

文章来自于"Founder Park"，作者 "Founder Park"。