人工智能代理时代的Transpareo

刚下班不久。合规负责人 从生产系统中导出班次表，将其放入 自己的助手程序中，并输入了一句话：“发布 该列表中各生产单元的产品护照。”

该助手读取了1240个序列号及其批次信息，向 Transpareo查询该产品所需的合格证，创建 合格证，并根据法规要求对其进行核验。 结果： 1237个符合要求，3个不符合，因为其中一个批次 缺少二氧化碳足迹数据。该批次补交了该数值 后，助手随即发布。两天后，这些 电池离开工厂，每块电池都附有一个二维码，扫描该二维码即可 查看其产品护照。

这并非未来场景：借助Transpareo Connect ，这一切如今已能实现。一名 助理在此处理一项合规任务 ** - 从委托到签字通过，**而Transpareo会在整个过程中 为他提供完成该任务所需的所有信息。

现在就试试吧

您在Claude、ChatGPT、Grok或Gemini上是否有 允许连接应用程序的账户？如果是，请将其与我们的 开放式演示版连接。这是一个“沙盒”：每小时都会重新初始化， 您在此期间的所有操作，到那时都会被清除。

1. 连接。在您的 AI 服务商处创建一个新的 MCP 服务器，地址为https://demo.transpareo.com/mcp 。根据服务商的不同，您可以在“连接器”、“ 集成”或“应用”栏目下找到该选项。
2. 共享。请使用tester 和Tester@12345 登录 - 此处特意显示了登录凭据。随后出现的屏幕 会逐一列出各项权限。对于只读权限， 您可以永久授予；而写入权限则 最好逐项确认。
3. 提问。回到聊天窗口后，请用 日常语言提问，例如 “列出我们的产品护照。”

要求提供一份清单；结果却读出了现状。

返回的结果不仅包含您查询的内容，还包括 这些内容的状态。之所以能实现这一点，是因为该接口 提供的信息比行本身更全面：包括行数、它们在 简历中的位置，以及缺失的内容。

这就是撰写这篇文章的原因。下文将解释为什么它 能奏效。

说做就做

需要对接的只有一侧：将助手与Transpareo对接，也就是 刚才提到的那三个步骤。另一侧则是一个 生产系统本就会输出的文件。没有人规定哪一 列对应哪个字段，也没有人维护接口： 向导读取了列表并写入了通行证，而 它需要执行的操作仅用一句话就说明清楚了。如果列表发生变化， 只需修改一条给向导的指令， 无需修改任何程序代码。

您的系统无需具备任何特殊功能。它只需输出 原本就会输出的内容：导出文件、报告中的列表， 以及班次结束时的表格。

而且不必是表格。无论是 供应商的数据表、PDF 文件还是邮件往来记录：助手都能从中 读取数据，并将其转换为 Transpareo 要求的格式。因为 Transpareo 会明确指定这种格式，而不是让用户 去猜测。 产品数据很少以结构化形式存在，而是散见于 各类文档中，而从这些文档中提取数据，多年来一直是 处理流程中的瓶颈。

该列表也可以手动导入。应用程序管理器中的 导入工具会接收表格，为 已识别的列命名，在生成数据前检查导入过程，并 可在需要时撤销操作。 结果 本会是一样的。只是需要有人确认字段映射、 阅读报告，并亲自补全那三个缺失的值。 向导并非改变“能否做到”，而是 改变“需要多长时间”。

以往在每个 合规项目启动之初就开展的整合工作，如今可以用一句 通俗易懂的话来概括。

这才是真正的革命。前提是另一端的 平台能够向程序明确其需求。

程序一直以来都是主要的“读者”

产品护照很少被人工阅读。它会被扫描、 调取、核验、转交并归档，其中大部分 工作由软件完成：商家的收银系统、 回收商的系统、政府部门的检测工具，以及希望 了解某批次产品是否符合标准的进口商。因此，大多数读取者 并不是用眼睛来读取产品通行证，而是通过程序来完成。

因此，Transpareo是围绕其接口构建的。每个 发布的证书都是经过签名的、可机读的 文档，且该接口覆盖了整个生命周期： 从产品的属性类型，到验证和创建， 再到发布以及单个 。而且该接口具有版本控制：今天为它 开发的人，绝非在沙上建屋。因此，新之处并不在于 程序使用“护照 ”，而在于具体使用哪些程序。

正因如此，助理的工作并不仅止于创建。 这种句式贯穿了简历的其余部分：

• “召回 批次B-2214的所有通行证。”
• “为第88批更新二氧化碳数值。”
• “给我看看本月送去维修的所有通行证 。”

这些语句中的每一条都会触发与用户在 应用程序管理器中执行的操作相同的调用，并在 审计日志中留下相同的记录。

一名助理必须能够提问，而不是猜测

助理是一位工作效率极高、但对贵公司 一无所知的员工。他只会按指示行事，如果 不给他明确的答案，他就会凭猜测来填补空白。有四件事 能让这种“猜测”转化为实际工作。

它必须能够查询具体要求。针对每种产品和 每个粒度级别 ，该平台都会告知护照需要哪些标识符和 属性，以及其中哪些信息已存储在产品 中。以单件产品为例，情况如下：

{
  "identifiers": {
    "batchIdentifier": { "required": true },
    "modelIdentifier": { "required": true, "source": "product", "value": "4006381333931" },
    "serialIdentifier": { "required": true }
  }
}

这三个标识码中，有两个必须由助理获取，第三个 已经标注在产品上了。这是一份工作指示，不是 猜谜环节。

它必须能够在不写入数据的情况下进行验证。一次验证会 执行与发布相同的检查，但不会 写入任何数据 。正因如此，在上文中，数字1237在任何内容 发布之前就已变为3。

他必须明白某项内容为何被拒绝。拒绝通知 会指明具体字段，并说明应采取的措施：

PRODUCT_INVALID: Product invalid
Correct the attributes listed under fields and resend the request.
  brand: Brand needs a brand - none was given
  componentsInput: Components input missing

一位阅读此信息的助手会补充两项信息，然后 再次发送。而只收到一个错误编号的人，则会尝试 各种方法。这正是人在命令行中 所看到的相同内容。

它绝不能数错。如果连接中断， 即使助手再次尝试，也只会产生一次 调用，而不是两次。写入式调用携带一个密钥， 平台会根据该密钥识别重复调用。

每次访问都可以撤销

处理您数据的程序越多，就越需要明确 谁拥有哪些权限。访问权限会在应用程序管理器中创建， 且仅显示一次密钥。此后，该 程序将使用一小时后失效的令牌，而 密钥仅会传输至签发令牌的源头。 该密钥 存储在操作系统的密钥串中，绝不会以 命令行参数的形式存在 - 否则它就会出现在每个进程列表中。

每个访问权限都仅具备您授予的相应权限： 读取权限是 一种， 写入权限是另一种，发布权限是第三种，且 可将其限制在特定产品范围内。不可逆的 操作还需额外确认。

当助手通过浏览器建立连接时，在 授权之前会弹出一个界面，列出其 所需的每一项权限。 一旦授权，该连接将显示在 “访问记录”页面上，并附有授权人员的 姓名和日期，该连接也可在此处被取消。

一种无法撤回的访问权限，并非 真正的访问权限，而只是门垫下的钥匙。

您的数据始终由您掌控

AI服务商接收的数据，正是您通过 助手调取的内容 - 至于使用哪款助手，以及它是否在 欧盟境内进行数据处理，由您决定，而非我们。只有 在您启用了翻译功能的地方，且仅供您 自己使用。负责 建立连接的工具运行在您自己的计算机上，其 源代码是公开的：您的安全部门可以查阅它 的具体运行情况，而不是仅凭信任。

对于一家欧洲企业而言，这是至关重要的 环节。该平台本身位于德国的ISO 27001认证 数据中心内；数据后续流向何处， 完全取决于您选择的助手。 您可以选择 在欧盟境内进行数据处理的助手，也可以选择数据 永远不会离开您企业的助手：transpareo mcp 可在 您自己的计算机上运行该协议，而背后采用何种模型， 则由您自行决定。

此外，产品护照中究竟包含哪些内容？通常来说， 这些都是产品数据：序列号、批次、材料、 测量值。 一旦涉及个人相关信息， 将由您自己的规则决定谁可以查看，并且 访问权限可以精确定制：仅限查看、仅限 特定产品，且可随时停用。

几分钟内就能设置好

对于您自己的工作区也是如此，它有 自己的地址，例如https://dpp.example.com/mcp ： 同样只需三个步骤， 无需安装任何内容。

如果更喜欢键入命令或将流程封装成脚本，那就使用 命令行。transpareo 是一个独立程序，其 命令由接口描述自动生成：平台 能做到的，该工具也能做到，无需人工 手动调整两者。 它采用开源模式，托管于 GitHub。只需三 行操作：安装、登录、查看该账户的权限范围。

curl -fsSL https://transpareo.com/cli/install.sh | sh
transpareo auth login --host dpp.example.com --client-id <id>
transpareo me

该程序由auth login 从标准输入或 某个环境变量中读取该密钥，绝不会从参数中读取 - 否则该密钥 将会出现在进程列表和Shell历史记录中。随后， 同一二进制文件会依次处理这些流程：

transpareo dpps requirements --product-id 8 --granularity item
transpareo dpps validate --file passport.json
transpareo dpps create --file passport.json
transpareo dpps publish <code>
transpareo events tail --follow

如果您的计算机上正在运行一个助手，则通过 另一行将其连接起来：

transpareo setup claude

这些操作随后将作为工具提供，名称与 上述命令相对应：dpp_requirements 、validate_dpp 、create_dpp 、publish_dpp 、tail_events 。无论您在 命令行中输入什么，还是由向导调用什么，都是相同的。 此外，还提供了一份面向助手的指南，其中描述了常规 操作流程，这样大家就不必通过反复 试错来掌握操作顺序了。而那些更喜欢直接编程的人，可以在每个 工作区中通过/apidocs 查阅 接口的完整说明。

聘请一名助理无需额外费用

无需额外费用。助手以 API用户的身份进行连接，而程序访问权限 已包含在所有Transpareo套餐中。计费依据是已发布的通行证数量，而非 参与处理的人员或程序数量。凡是实现合规工作 自动化的用户，均不会因此收到账单。

工作始于职责之前

从2027年2月起， 电池产品护照 将具有法律约束力，其他产品类别也将陆续跟进。真正的投入并不 在于护照本身，而在于整理产品数据，而企业正是将这些 工作正是企业目前委托给助理完成的：汇总 字段信息、查找缺失数据、跟进供应商信息、 核查、重复操作。关于这些数据究竟如何 进入证书，《一条电流，一个方向》一文进行了说明；而关于如何构建专属的对接方案，《ERP对接指南》则提供了详细指导。

一个只能靠猜测的助手生成的护照虽然 看起来合情合理，却经不起核查。而一个 能够提问的助手生成的护照则是真实的。这种差异 并非源于助手本身，而是源于它 所依赖 的平台。