Records——智能体收集到的东西最终去哪里

一个甄别完咨询、然后把它留在对话记录里的智能体，只做了一半活。Records 是另一半：控制台里的一个队列，每条对应一件需要真人处理的事，产生它的那段对话就在一次点击之外。

这里没有任何东西需要配置。当初始设置向导创建一个智能体时，它也会接上这些工具，于是一个声称自己会“把一份结构化文件交到你团队手上”的模板，现在真的有地方可交了。

智能体会归档什么

一条 lead 或一条 checklist 会更新它所属对话的那条记录，而非再造一条，于是一个在同一场对话里归档两次的智能体会自我修正，而不是把你的队列塞乱。一条 booking 和一条 escalation 每次都各创建一条，因为这两者中的两条是两件真实的事。

编号

每条记录都会拿到一个简短编号——7K4M-2QP——由一套没有 O/0、也没有 I/1 的字母表构成，因为它会在电话里被念出来、再被错误地敲回去。智能体会把它给到你的客户，方便他们日后来查询。

这个编号不是一把访问密钥。一次读取是由提问者的身份来授权的，这身份从对话里带过来，所以报出一个别人无意中听到的编号，什么也返回不了。

从你自己的技术栈里使用这些工具

两个接口，同一套行为。你的令牌在控制台的 Tenant & API 下面。

MCP

对于向导创建的智能体已经接好了。要把它接到别处，就把一个 streamable_http MCP server 指向 https://agent4.io/api/mcp，并带一个 Authorization: Bearer 头。工具：submit_lead、open_checklist、request_booking、escalate、lookup_case、close_case。

HTTP

curl -X POST https://agent4.io/api/tools/records \
  -H "Authorization: Bearer $AGENT4_TOOL_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
        "type": "lead",
        "title": "Sarah — quote for a home policy",
        "summary": "Wants contents cover on a flat she has just bought.",
        "contact": { "name": "Sarah", "phone": "07700 900000" },
        "fields": { "sumInsured": "40000", "startDate": "2026-08-01" }
      }'

{ "reference": "7K4M-2QP", "created": true, "message": "Recorded. The reference is 7K4M-2QP …" }

用 PATCH /api/tools/records/{reference} 加 {"outcome":"quoted"} 结掉一条。用 GET /api/tools/records/{reference} 读一条，它需要该记录所属之人的 X-Agent4-End-User。

字段

title、summary、contact 和 urgency 在每个行当里都一样——它们是队列用来排序和展示的东西。其余一切都进 fields，而每个模板会声明它所在行当收集的键，于是 telephone 在进来的路上会被折叠到 phone 上。一个没有任何模板声明过的键会被保留而非丢弃；它会出现在记录的“也提到了”下面。

被通知

一个没人被告知的队列，就是一个没人读的队列，所以 Notifications 就坐在队列本身上。两个渠道，你按类型选择哪些会触发。

Email 会发到你的登录地址，除非你另指定一个——付费的人很少是处理队列的人。开箱即用时，升级请求和预约请求会发邮件给你，而咨询不会：一个每来一条咨询就叮一下的收件箱会被静音，而这也会把升级请求一起噤声。

Webhook。 记录一被归档，我们就把它 POST 到你的 URL：

{
  "event": "record.created",
  "record": {
    "reference": "7K4M-2QP",
    "type": "lead",
    "title": "Sarah — quote for a home policy",
    "summary": "Wants contents cover on a flat she has just bought.",
    "contact": { "name": "Sarah", "phone": "07700 900000" },
    "fields": { "sumInsured": "40000", "startDate": "2026-08-01" },
    "agent": "Front desk"
  },
  "url": "https://agent4.io/dashboard/records/7K4M-2QP"
}

它带两个头：X-Agent4-Timestamp，以及 X-Agent4-Signature——一个对“时间戳、一个点、加原始正文”所做的 HMAC-SHA256，用设置页上的签名密钥加密。验证它，你就知道这个 POST 是我们发的，而不是某个学到了 URL 的人。时间戳在签名内部，所以一个被截获的请求日后无法被重放到你这里。

expected = hmac.new(secret.encode(), f"{ts}.{raw_body}".encode(), hashlib.sha256).hexdigest()
hmac.compare_digest(expected, request.headers["X-Agent4-Signature"])

这个 URL 必须是 https，且从公网可达——一个只在你网络内部解析的地址，会在你保存时被拒绝，而不是每次有记录到达时都无声地失败。在你依赖它之前，从设置页发一个测试；它会报告接收端实际说了什么。

这份载荷携带记录的内容，包括联系方式——一个略去它们的 webhook 不足以开一张工单，而开工单正是它存在的目的。所以你指向的这个端点会接收到你客户的个人数据，值得和你保存这类数据的任何别处一样的谨慎对待。

把一条交给同事

无需第二个账户。打开一个链接发过去即可——在 WhatsApp 上，或作为一个别人从你屏幕上扫的二维码。结案会关闭该链接，于是撤销是作为完成工作的一部分发生的，而不是一件要另外记住的事。把一个链接关掉再重新打开，会生成一个不同的链接，所以对还持有旧链接的人来说，“关闭”是真正意义上的关闭。

你也可以打印一条记录。一份打印件没有过期时间，也无法被召回，这在它离开这栋楼之前值得多想一会儿。

离开

随时都能从队列里把每条记录导出为 CSV。如果你成长到超出了这里、转去用一个 CRM，智能体照常工作——记录是你的，它们跟你走。

我们存什么，以及怎么存

一条记录的全部内容——标题、摘要、联系方式、笔记——在静态存储时都加密。只有队列用来排序和筛选所需的东西留在明文列里：类型、状态、时间戳，以及指回那段对话的标识符。这些没有一个能识别出一个人。

由此带来的、我们有意接受的后果是：我们无法用一次数据库查询在你的记录内部搜索。筛选是按类型、状态、智能体和日期进行的。

记录是你客户的个人数据，代你保管。从控制台删掉一条，或全部删掉；关闭你的账户会连同它们一起移除。