快速上手

核心概念

本平台使用的术语,以及每个术语在机制上究竟对应什么。值得花二十分钟读完——大多数智能体问题,根源都是对其中某个概念的误解。

模型,以及它做不到的事

语言模型本质上是一个从文本到文本的函数。它在两次调用之间没有记忆,无法访问你的文件,也无法对现实世界采取任何行动。本平台的其余一切能力,都是为了绕开这三个限制之一而存在的。

它同样没有“真假”的概念,只有“像不像”。当你让模型给出一个它无法计算的合计值时,它会返回一个 看起来像 合计值的数字。这不是靠更好的提示词就能修掉的缺陷,而是这台机器的本质。可靠的做法是:绝不向它索取需要它凭空编造的事实,而是把由确定性手段检索到的事实交给它。

智能体

所谓 智能体 ,是一份保存下来的配置:系统提示词、模型、一组被许可的工具、可选的知识与数据、记忆设置和护栏。它并不是一个持续运行的进程。每次你与它对话时,平台都会把这些部件重新组装成一次请求。

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 支出上限 ,设在用户组或凭据上盯着分析页面然后手动干预——等你发现时钱已经花完了

为什么这样设计

几乎每一条“模型不够强”的反馈,背后都是上面某个选择做反了。更大的模型不会让文字变得算术准确,不会把一句提示词变成强制关卡,也不会在对话结束后记住任何东西。

术语速查

术语含义
令牌一小段文本(约相当于 ¾ 个英文单词)——模型计费和限额都以它为单位。
温度随机性。抽取和分类用低值,起草文稿用高值。
系统提示词附加在每一轮开头的长期指令。
向量嵌入语义空间中的一个数值坐标,用于查找相关文本。
分块文档中一个可被检索的片段。
上下文窗口模型一次能够处理的最大文本量。
MCPModel Context Protocol(模型上下文协议)——一种向任意智能体开放工具的标准方式。
幂等键由客户端提供的标识,确保重试的 API 运行只会真正执行一次。