跳到主要内容

基础概念

概念全景​

层概念回答什么问题
服务Agent Service你在卖什么
能力角色与提示词 · 知识库 · 技能 · 应用授权 · 业务本体Agent 会什么
对象联系人 · 会话 · 双流消息Agent 在服务谁
质量测试集 · 评估维度 · 版本与回归Agent 做得够不够好
运行Agent 运行时 · 沙箱 · 租户隔离Agent 跑在哪、安不安全
回路人工介入 · 持续学习 · InsightsAgent 怎么越用越好

它们之间的依赖关系：

业务本体 ──┐
知识库   ──┼──▶ Agent ──▶ 会话 ◀── 联系人
技能/
应用授权  ─┘              │
                           ▼
                      交互数据
                       ├─ 坏例 ──▶ 测试集 ──▶ 评估 ──▶ 新版本 Agent
                       └─ 好例 ──▶ 知识库 ─────────────┘

这条回路是 OpenHex 与「配置完就不管了」的产品之间最本质的区别：服务跑得越久，资产沉淀越厚。

一、Agent 与 Agent Service​

最容易混淆的第一对，也是最重要的一对。

Agent 是一个配置好的角色与能力集合——它有身份、有边界、会调用工具、能读知识库。它是一个技术对象。

Agent Service 是一门生意——它有客户、有交付、能收钱、有运营记录。它是一个商业对象。

一个 Agent Service 由一个 Agent 对外呈现，但背后挂着联系人库、知识库、测试集、用量账单和运营数据。你卖的是后者，不是前者。

判断标准​

一个 Agent 是否已经构成 Agent Service，问三个问题：

  1. 客户知道它存在吗？ —— 客户从头到尾没见过它，它只是个内部工具。
  2. 它自己收钱吗？ —— 收款发生在它之外，它只是个辅助环节。
  3. 它停了，生意会停吗？ —— 不会，那它不是你的服务主体。

三个都是「是」，才是一门 Agent Service。

二、角色与提示词​

是什么：定义 Agent 的身份、职责范围、说话方式与行为边界。一处配置，全局生效。

与知识库的区别：角色决定它怎么说话、能做什么、不能做什么；知识库决定它知道什么。同一份知识库，配上「严谨的法务顾问」和「热情的售前」两个角色，产出完全不同。

语气边界是可评估的：角色设定不是写完就算，它是能力评估的五个维度之一——Agent 有没有越界承诺、有没有用错语气，发布前会被测出来。

反蒸馏：市面上多数 Agent 的能力全写在提示词和工作流里，等于把知识产权挂在墙上。OpenHex 的提示词与流程在受保护层执行，不随对话输出——客户用得到你的能力，复制不走你的方法。

三、知识库​

是什么：Agent 的资料来源。上传文档自动解析入库，支持混合式检索。

与业务本体的区别（这一对常被混为一谈）：

对比项知识库业务本体
内容形态非结构化资料——文档、手册、案例、合同模板结构化业务事实——实体与实体之间的关系
回答什么「我们的退货政策是怎么写的」「这个客户上次成交价是多少」
怎么用检索后进入上下文直接进入 Agent 上下文
怎么维护传文档用 UI 定义实体与关系

一句话：知识库是资料，本体是事实。

与持续学习的关系：真实交互中被判定为「好例」的问答会自动回流进知识库，知识库不是静态的。

四、技能与应用授权​

技能（Skill） 是 Agent 能执行的动作——生成报价单、跑一段分析、起草一份文书。它描述「能做什么」。

应用授权（Connector） 是通往外部系统的通道——CRM、ERP、订单库、内部 API。它描述「能连到哪」。

一个技能可能需要零个或多个应用。「生成报价单」这个技能，可能要通过应用授权才能读产品库和汇率，也可能全靠本体里已有的数据。

凭据只在应用授权网关注入。 这是概念层就要知道的事：Agent 本身拿不到任何密钥，它只发出「我要调用这个工具」的意图，凭据由网关按次注入。所以即使 Agent 被提示词注入攻破，也拿不走你的密钥。

五、业务本体​

是什么：用 UI 定义业务实体与它们之间的关系，无需写代码。定义好的本体直接进入 Agent 的上下文。

举个具体的：外贸场景的本体包含产品库、价格体系、客户档案、历史成交价，以及它们之间的关系——哪个客户属于哪个区域、哪个型号对应哪一档阶梯价、这个客户上次买了什么。Agent 拿到询单时，不是去检索一堆文档，而是直接读到结构化的业务事实。

为什么它是可复制性的关键：同一套工作台底座，换一套业务本体就能复制到下一个行业。营销行业的本体是客户、项目、任务、交付；外贸行业的本体是产品、报价、订单、船期。平台不变，本体一换，就是另一个行业的 Agent Service。

六、联系人与会话 ★​

这是 OpenHex 最核心、也最容易被误读的一组概念。

多数产品里，「用户」是会话的一个属性——会话结束，用户信息也就散了。

OpenHex 里反过来：联系人脱离会话独立存在。

对比项联系人（Contact）会话（Session）
是什么一个真实的服务对象一次具体的服务过程
生命周期长期存在，跨会话、跨渠道有始有终
承载什么身份、历史、标签、数据权限消息、工具调用、交付物、可回放的完整记录
数量关系1N

这意味着什么​

  • Agent 会认人。同一个客户今天在微信问、下周在官网问，Agent 知道是同一个人，知道上次谈到哪、答应了什么价。
  • 权限跟着人走。不同联系人有不同的数据权限——同一个 Agent，A 客户能看到的和 B 客户能看到的不是一回事。
  • 客户会沉淀成资产。服务记录不散落在聊天窗口里，而是长在联系人档案上。换个工具不会归零，跑得越久越值钱。
  • 每次服务可回放可审计。会话是完整记录，不是聊天记录。

没有这一层，Agent 每次都从头开始，服务无法积累——那是工具，不是服务。

七、双流消息：脑口分离 ★​

是什么：Agent 的输出被拆成两条独立的数据流。

数据流内容谁能看到
event stream推理过程、工具调用、中间状态只在后台，可审计
reply stream最终要说给客户的那句话客户端

思考过程和工具调用对客户不可见。完整推理链在后台可审，客户端只收到该收到的内容。

  1. 它决定了你在客户端能渲染什么。 如果你用 SDK 把 Agent 嵌进自己的 App，你收到的是 reply stream，不是全部——这个约束要在设计界面时就知道。
  2. 它保护你的方法。 竞争对手拿不到你的推理链，也就复制不走你的专业判断过程。这是反蒸馏的一部分。
  3. 它专为谈判类场景设计。 报价、议价、条件磋商这类场景里，把内部盘算暴露给对方是灾难性的。脑口分离让这类场景在架构上就是安全的

八、测试集与能力评估 ★​

问题：你怎么知道这个 Agent 可以放出去见客户？

多数产品的答案是「上线试试看」——让客户当测试员。OpenHex 的答案是发布前的确定性。

测试集​

一组带预期的真实问题。两个来源：

  • ai拟测试集 —— 系统自动生成
  • 自定义测试集 —— 用你自己的真实客户问题构建

五个评估维度​

维度测什么
准确性答案对不对
专业度够不够行业水准
语气边界有没有越界承诺、有没有用错口吻
工具调用该调的调了没有、调对了没有
交付完整度客户要的东西是不是真的交付了

版本回归与发布闸门​

版本之间自动回归对比，您认为达标才允许上线。不是「建议你测一下」，是发布流程里的一道闸门。

九、Agent 运行时与沙箱​

这是两个东西，两个独立的 Pod，各自预热、各自伸缩。分开是有原因的。

Agent 运行时（Agent Runtime）​

一实例多会话，常驻。负责推理与对话。

因为常驻，空闲会话恢复是 0 秒——客户三天后回来接着聊，不需要等唤醒，也不需要为了保持热度而付全价。

Agent 沙箱（Agent Sandbox）​

按需拉起。每个会话随时可获得一个完整沙箱：能跑代码、装依赖、读写文件、连外部系统，撑得住复杂长程任务的交付。

关键在于：只在执行时计费，不为空等付钱。

为什么要分开​

场景如果合成一个分开之后
空闲会话要么慢（唤醒 1–10 秒），要么贵（付全价保温）常驻运行时，0 秒恢复，成本极低
突发并发每个会话新建一个完整沙箱，控制面压力大运行时承接会话，沙箱只在真正执行时拉起
计费活跃与空转同价空等不计费

十、租户与数据隔离​

概念层你需要知道三件事。

三层隔离：

  1. AI Sandbox —— 负责推理与对话，看不到任何密钥，只传出工具调用意图
  2. Tooling Sandbox —— 负责工具调用与外部系统访问，看不到 Prompt 与对话上下文，只取本次调用凭证
  3. Vault Service —— 保管密钥与凭证，按次签发，密钥不落地到任何 Sandbox

结果：提示词注入攻不到密钥，工具被攻破也读不到对话，密钥本身谁都拿不到。

多租户隔离在文件系统层，运行时启动时动态 mount，走系统原生权限管理。租户之间物理不可达，按需挂载、用完即卸。

→ 完整机制见安全架构

十一、人工介入、持续学习与 Insights​

服务上线不是终点，是一条回路的起点。

人工介入：用户可随时介入服务保证质量。介入这个动作本身是有价值的数据——介入数据自动打标，进入下一轮学习。

持续学习：真实交互沉淀为下一轮训练的原料。

  • 坏例 → 进测试集，成为下个版本的发布门槛
  • 好例 → 进知识库，成为下次回答的依据
  • 全部交互 → Insights 自动打标

Insights：自动识别意向客户、流失风险与高价值客户，把该跟进的人推到你面前。

Agent 的智力不来自换一个更强的模型，而来自它身后的数据资产。会话、联系人、知识库、业务本体在同一层被治理起来，跑得越久沉淀越厚——这是客户换不走的东西。

最容易混淆的五对概念​

这一对一句话区分
Agent vs Agent ServiceAgent 是技术对象，Agent Service 是商业对象
知识库 vs 业务本体知识库是资料，本体是事实
技能 vs 应用授权技能是「能做什么」，应用授权是「能连到哪」
联系人 vs 会话联系人长期存在，会话有始有终；1 对 N
运行时 vs 沙箱运行时常驻负责对话，沙箱按需拉起负责执行

术语英文对照​

中文英文状态
Agent 服务Agent Service✅
一人服务One Person Service（OPS）✅
联系人Contact✅
会话Session✅
知识库Knowledge Base✅
技能Skill✅
应用授权Connector✅
测试Test Set / Eval Set⚠️ 待统一
业务本体待定名⚠️ 需定名
脑口分离待定名⚠️ 需定名
反蒸馏待定名⚠️ 需定名