快速上手
核心概念
本平台使用的术语,以及每个术语在机制上究竟对应什么。值得花二十分钟读完——大多数智能体问题,根源都是对其中某个概念的误解。
模型,以及它做不到的事
语言模型本质上是一个从文本到文本的函数。它在两次调用之间没有记忆,无法访问你的文件,也无法对现实世界采取任何行动。本平台的其余一切能力,都是为了绕开这三个限制之一而存在的。
它同样没有“真假”的概念,只有“像不像”。当你让模型给出一个它无法计算的合计值时,它会返回一个 看起来像 合计值的数字。这不是靠更好的提示词就能修掉的缺陷,而是这台机器的本质。可靠的做法是:绝不向它索取需要它凭空编造的事实,而是把由确定性手段检索到的事实交给它。
智能体
所谓 智能体 ,是一份保存下来的配置:系统提示词、模型、一组被许可的工具、可选的知识与数据、记忆设置和护栏。它并不是一个持续运行的进程。每次你与它对话时,平台都会把这些部件重新组装成一次请求。
your message
│
▼
┌──────────────────────────────────────────┐
│ system prompt + retrieved context │
│ + conversation history + tool definitions│
└──────────────────────────────────────────┘
│
▼ model decides: answer, or call a tool
│
├─ tool call ──▶ platform runs it ──▶ result appended ──┐
│ │
│◀───────────────────────────────────────────────────────┘
▼ (loop until the model stops asking for tools)
final answer + sources关键在于这个循环。模型并不会“使用”工具,它只是发出一个使用工具的请求,由平台执行,再把结果作为新的文本喂回去。一个看起来无视自身工具的智能体,通常是因为它的提示词或工具描述没能让选择变得显而易见。
工具
A 工具 ,是模型可以按名称请求调用的函数,带有描述和类型化的参数结构。这里的描述不是给人看的文档——它是模型判断要不要调用该工具的唯一依据。平台提供的工具如下:
| 工具 | 作用 | 适用场景 |
|---|---|---|
kb_search | 在你的知识库中做语义搜索 | 答案以文字形式写在某处 |
sql_query | 对已接入的表执行只读 SQL | 答案需要计数、筛选或聚合 |
metric_query | 来自语义层的受治理度量 | 该数字有统一约定的定义,不允许重新推导 |
web_search | 通过 Firecrawl、Brave、Tavily 或 SerpAPI 实时搜索 | 答案不在你的数据里,而且会随时间变化 |
web_browse | 抓取并读取单个网页 | 你有一个值得完整阅读的具体网址 |
mcp_call_tool | 调用已连接 MCP 服务上的工具 | 该能力归属于另一个系统 |
calculator | 算术运算 | 任何算术运算——绝不要让模型心算 |
为什么这样设计
检索,也就是 RAG
检索增强生成的含义是:在向模型提问之前,先去找到相关文本,把它放进提示词,并要求模型只依据这些内容作答。
在本平台上,具体机制如下:
- 你的文档会被切分成若干 分块 ,每块几百字。
- 每个分块会被转换成一个 嵌入向量 ——一组把它定位在语义空间中的数字,因此“退款期限”会落在“退货期”附近,即便二者没有一个字相同。
- 你的问题会以同样方式转换成向量,最接近的若干分块被取回,并带编号引用放入提示词。
这也解释了检索失败的两种典型形态。如果包含答案的分块压根没被检索到,模型就会凭通用知识作答,而且听起来毫无破绽。如果你的提问措辞与原文差异很大,最接近的分块就会是错的。这两种情况都能在 追踪记录 中看到——在责怪模型之前,先看看究竟检索到了什么。
注意
智能体集群
A 集群 是由节点构成的图:智能体、按条件分支的路由器、循环、并行分发、人工审批关卡、代码函数和工具节点。输出沿着连线流动。
只有在满足下列条件之一时,才把一个智能体拆成多个:
- 各项任务需要不同的工具。 一个需要浏览网页的研究员,和一个绝不该联网的写作者,本就该干净地分开。
- 某个步骤必须经过检查才能继续。 在路径中放置一个审批节点。
- 工作可以并行进行。 三项独立分析并行展开,再汇合。
除此之外,优先使用一个做得好的智能体。每多一跳,上下文就多一处可能在摘要中丢失,而多智能体图的排查难度远高于单条提示词。参见 集群画布.
记忆
有三样不同的东西都被叫做“记忆”,它们的行为并不相同:
| 类型 | 存续时长 | 它是什么 |
|---|---|---|
| 上下文窗口 | 单次请求 | 随本次调用一起发送的对话记录。容量有限,最早的轮次会先被挤出。 |
| 短期记忆(STM) | 单次对话 | 对早前轮次的滚动摘要,使长对话不会因窗口限制而中断。 |
| 长期记忆(LTM) | 跨多次对话 | 智能体选择记住的持久事实,按与当前消息的相关性被召回。 |
长期记忆按智能体单独选择启用,并以普通数据行的形式存储,你可以查看和删除。对话历史有自己的保留期,参见 数据保留期.
护栏
护栏运行在 模型之外 ,分别作用于输入和输出两条链路——正因如此,即使提示词被诱导去无视自身指令,护栏依然有效。它们可以拦截话题、强制要求引用,并在数据到达提供商之前识别或脱敏个人信息。参见 护栏与 PII.
BYOK — 谁的密钥在付费
自带密钥。 你接入自己的提供商凭据(OpenAI、Anthropic、Bedrock、Vertex、Azure 等),调用将计费到你的账户、按你的费率、依据你与该提供商签订的数据协议执行。运维方的共享密钥只是一个免配置的兜底,让新工作区在尚未接入任何凭据前也能运行。
这是一项治理属性,而不只是计费细节:提示词和文档流向的是你自己选定、并与之签有合同的提供商。至于某个用户可以使用哪些模型,则由另一处单独控制: 访问控制.
追踪记录
每一次模型调用和工具调用都会被记录:展开后的提示词、参数、结果、令牌数、延迟与成本。追踪记录是智能体行为的唯一事实依据——智能体对自身推理过程的陈述同样是生成出来的文本,可能是错的。在这里排查问题,顺序永远是先读追踪记录,再形成判断。
我到底该用哪一个?
上面这些概念彼此有不少重叠,所以真正常见的问题不是“检索是什么”,而是“这到底是检索问题还是数据问题”。下面这张对照表能解决其中大部分:
| 你想要的效果 | 应该用 | 而不是 |
|---|---|---|
| 忠实引用文档内容作答 | A 知识库 | 把文档塞进一条长系统提示词——每轮都要付同样的令牌成本,而且依然无法给出引用 |
| 一个必须算得准确的数字 | 一张表,配合 sql_query — 数据目录 | 检索。模型从文字中读出一个数字,本质上就是在自信地猜 |
| 一个所有人都必须按同一口径计算的定义 | A 语义层度量 | 在每个仪表板里各写一遍 SQL,四份副本迟早各走各的 |
| 对自有数据的一次可复用加工 | A 预处理表 | 在每个需要它的图表里各建一个计算字段 |
| 必须按固定顺序执行、并有人工把关的流程 | A 集群 配合审批节点 | 一个智能体加一句“先请示”的提示词——提示词只是建议,关卡才是关卡 |
| 让智能体跨对话记住某些内容 | 长期记忆 长期记忆,按智能体单独启用 | 加大上下文窗口——对话一结束,它照样忘得一干二净 |
| 某些绝不能说出口或泄露的内容 | A 护栏,它运行在模型之外 | 写在系统提示词里的一条指令——而被诱导的提示词,恰恰就是用来让它违背这条指令的 |
| 防止某个团队把预算全部花光 | A 支出上限 ,设在用户组或凭据上 | 盯着分析页面然后手动干预——等你发现时钱已经花完了 |
为什么这样设计
术语速查
| 术语 | 含义 |
|---|---|
| 令牌 | 一小段文本(约相当于 ¾ 个英文单词)——模型计费和限额都以它为单位。 |
| 温度 | 随机性。抽取和分类用低值,起草文稿用高值。 |
| 系统提示词 | 附加在每一轮开头的长期指令。 |
| 向量嵌入 | 语义空间中的一个数值坐标,用于查找相关文本。 |
| 分块 | 文档中一个可被检索的片段。 |
| 上下文窗口 | 模型一次能够处理的最大文本量。 |
| MCP | Model Context Protocol(模型上下文协议)——一种向任意智能体开放工具的标准方式。 |
| 幂等键 | 由客户端提供的标识,确保重试的 API 运行只会真正执行一次。 |