你上线了一个 AI Agent。它在生产环境中运行，会话正常开始和结束，监控仪表盘上的指标也一切正常。但随后，有用户反馈说：为了完成一个任务，他们花了整整十分钟，不断修改参数、重试同一条失败的命令，最后还是放弃了，换了一种方式重新提出请求。
问题出在哪里？你的监控指标根本没有捕捉到这种糟糕的用户体验。从基础设施的角度来看，一切正常：任务启动了，任务结束了，Token 也正常计费了。
指标可以告诉你一次运行已经结束，却无法说明它执行得好不好。AI Agent 具有非确定性，同样的提示词，周一可能运行顺利，到了周二却可能出现各种问题。所有线索其实都在对话记录中，但一段对话可能包含数千个事件，而生产环境中的 AI 产品每天可能产生数百段这样的对话。显然，靠人工逐条阅读对话记录并不可行。让另一个大模型为每段对话打分似乎也能解决问题，但当评估费用逐渐接近运行 Agent 本身的费用时，这种方式就不那么划算了。
DigitalOcean Signals 现已开启公测（Public Preview）。在获得你的授权后，它可以监测 DigitalOcean 托管 Agents（Harness Runtime）和 DigitalOcean 推理引擎 中的生产环境对话，并将其转化为结构化的行为信号。这些信号能够帮助你发现用户在哪一步感到沮丧、Agent 在哪里陷入循环、哪个工具持续调用失败、会话何时触发速率限制，以及何时耗尽上下文。每条信号都会指向产生该问题的具体对话步骤，让你只需几次点击，就能从“这个 Agent 好像有点问题”定位到“问题就出在这一轮”。
并非所有信号都代表问题。满意度信号会标记用户确认答案、表达感谢或成功达成目标的会话。你也可以通过 DigitalOcean Signals 了解 Agent 的任务成功率，以及成功的对话有哪些共同特征。由于被标记的会话可以导出为数据集，生产环境中的真实案例还能成为评估和改进 Agent 的素材。
Signals 核心功能一览：
- 以用户授权为前提。 默认关闭，可按环境单独启用；授权操作会被记录，也可以撤销，并支持按需删除数据。
- 目前支持两种数据来源。 基于 Harness Runtime 的托管 Agents 服务，以及 推理引擎 中的对话（公测期间支持通过 API 和
doctl使用）。 - 三层信号体系。 涵盖交互、执行和环境三个层面，共有 25 种信号类型，每种信号都会指向产生它的具体步骤。
- 无需额外埋点。 直接使用平台已经生成的对话数据流，不需要修改 Agent。
- 无需调用大模型进行检测。 采用确定性信号检测，成本不会像逐段对话调用大模型评估那样随流量增长。
- 以证据为依据，而非主观判断。 每条信号都包含对应的运行记录、步骤、置信度和文本片段。
- 不止于仪表盘，还能生成数据集。 导出的数据可直接用于 Evaluations 和 Simulations，构建数据集和模拟场景。
- 公测期间免费使用。 托管 Agents 和 无服务器推理 中的 Signals 均无需额外付费。
Signals 会检测哪些问题
Signals 可以检测七个类别中的 25 种信号类型，并将它们归入三个层面。这套分类体系源于 DigitalOcean 团队今年早些时候在 arXiv 上发布的关于 Agent 执行轨迹问题排查 的研究。
Signals 涵盖以下三个层面及其信号类型：
- 交互信号（Interaction signals）：描述用户如何回应对话。目标偏差包括用户提出澄清问题、纠正 Agent 或换一种方式重新表述请求；停滞包括对话迟迟没有进展，或重复已经提供过的信息；用户失去参与意愿包括要求升级处理、表达负面态度或直接退出；满意度则包括确认答案、表达感谢和成功达成目标。
- 执行信号（Execution signals）：反映工具调用和操作是否成功。失败情况包括参数无效、查询错误、调用不存在的工具、在当前状态下执行无效操作，以及错误使用凭据；循环情况包括简单重试、参数漂移（使用略有不同的输入反复执行同一操作），以及在两个操作之间来回切换。
- 环境信号（Environment signals）：反映 Agent 所依赖的基础设施是否正常运行，包括外部 API 错误、上下文溢出、响应格式错误、网络故障、速率限制和超时。
Signals 直接根据交互内容生成信号，不需要在检测过程中调用大模型。检测过程具有确定性，成本也较低，因此即使流量增长，监测 Agent 的成本也不会随之大幅上升；相同的对话每次都会产生相同的信号。
Signals 的定位是第一轮问题筛查：它帮助你找出哪些对话值得人工审查，或者值得交给成本更高的大模型评估器进一步分析。这样，你就不必为全部生产流量支付人工审查或大模型评估的费用。
在一项基于 τ-bench 的受控研究中，研究人员将其作为工具调用型 Agent 的标准基准测试。标注人员发现，Signals 标记的会话中，有 82% 具有参考价值，也就是说，这些会话展示了真实的失败案例，或值得学习的优秀案例。相比之下，随机抽取的会话中，这一比例为 54%。简单来说，在相同的审查预算下，审查人员从 Signals 标记的会话中找到有价值案例的数量约为随机抽样的 1.5 倍。实际生产环境中的结果可能有所不同，但这项测试说明，Signals 有望帮助团队建立一套真正能够处理完的问题审查队列，而不是让问题堆积到最后无人理会。
需要注意的是，Signals 并不是评分系统。信号只是标记出值得进一步查看的会话。有时，这代表需要修复的失败；有时，它代表值得推广的优秀范例。Signals 会同时呈现这两类情况，将最终判断留给你和后续使用的工具。
Signals 如何工作
Signals 将每段对话组织为三个层级：
- 一次对话执行（dialogue）：指一次已经完成的运行，包括用户消息，以及 Agent 为回应该消息采取的各项步骤，按顺序记录每次工具调用、调用结果和任何人工审批。
- 一个会话（session）：由一次或多次对话执行组成。
- 一条信号（signal）：在对话中检测到的一种行为模式。
Signals 会为每个会话生成一份信号报告。报告会对对话的整体质量进行评估，评级范围从 Excellent 到 Severe，并列出检测到的信号、对应层级和类别，同时标记需要进一步检查的会话。
每条信号都包含触发信号的运行记录、步骤索引、置信度和简短的文本片段，因此你可以直接跳转到还原后的对话中，查看信号产生的具体步骤。会话在一段时间没有活动后会接受分析；当会话关闭或销毁时，系统还会再次进行分析。换句话说，如果开发者在数小时内多次返回同一个长期运行的编程会话，信号报告会持续更新，而不是只给出一次最终评估结果。请注意，Signals 视图中的指标可能需要最多一小时才能反映最新活动。
Signals 默认关闭，需要按环境单独启用。启用后，系统只会分析启用之后开始的对话。对话内容始终保留在你的 DigitalOcean 团队边界内，不会用于跨客户的大模型训练。导出数据时，系统会对自由文本中的个人信息进行脱敏，例如用户消息、步骤文本和文本片段。基于导出轨迹创建的模拟场景会使用未脱敏版本，以确保场景的真实性；但在向用户展示场景时，机密内容会被脱敏。
关闭 Signals 后，系统将停止收集新对话的数据；如果你提出删除请求，已收集的数据也会被删除。更多信息请参阅 Signals 数据隐私文档。
如何开始使用 Signals
Signals 目前处于公测阶段。你需要使用 doctl 1.181.0 或更高版本，并提供具有 signals:query 和 signals:update 权限范围的访问令牌（完整访问权限令牌已包含这两个权限）。公测期间，处于免费试用期的账户无法使用 Signals。
1、 为某个环境启用 Signals。 在控制面板中，打开 Harness Runtime 页面中的 Signals 选项卡，选择相应环境，然后打开开关。这一步用于记录你的授权，操作会被记录，并且可以撤销。
也可以通过命令行完成相同操作：
doctl signals consent set --agent-id <agent-id> --enabled=true
Agent ID 指的是 Agent 所运行的 Environment Config 的 ID，可以通过 doctl harness-runtime config list 查看。
Signals 同样支持 推理引擎 中的对话。在当前公测阶段，启用和读取 Inference Signals 只能通过 API 和 doctl 完成，控制台界面将在后续推出。
2、像往常一样使用 Agent。 Signals 会使用 Harness Runtime 和 推理引擎 已经生成的同一套对话数据流。你不需要额外埋点，也不需要修改 Agent 代码。 会话进入空闲状态后，通常会在 30 分钟内出现对应的 Signals 数据。
3、查看信号。 Signals 视图会列出最近的会话，并显示质量评级、信号数量，以及是否需要关注的标记。大多数会话不会出现明显问题，因为你可以先整体查看 Agent 的运行情况，只打开被标记的会话。进入某个会话后，你可以查看其中的对话执行记录，并直接跳转到触发信号的步骤。
通过命令行，你可以列出会话，并根据关注的问题类型筛选结果：
doctl signals session list --agent-id <agent-id> --signal-type ExecutionLoopsRetry
doctl signals session dialogues --session-id <session-id> --output json
JSON 输出中，每个对话执行对应一个对象，其中包含用户消息、执行步骤、运行状态，以及该次运行中检测到的信号：
{
"run_id": "5b4a3c2d-1e0f-4a9b-8c7d-6e5f4a3b2c1d",
"sequence": 2,
"user_message": "Deploy the latest build to staging.",
"steps": [
{ "seq": 1, "type": "agent_reply", "text": "I couldn't find a deployment tool." }
],
"run_status": "completed",
"signals": [
{
"signal_type": "ExecutionFailureToolNotFound",
"label": "Tool not found",
"layer": "execution",
"category": "failure",
"step_index": 1,
"confidence": 0.92
}
]
}
该视图中的所有信息也可以通过 Signals API 获取。
4、将会话导出为数据集。 选择需要导出的会话，也可以按信号类型和时间范围进行筛选，然后创建导出任务。Signals 会将会话、信号报告和完整对话打包成一个压缩的 JSON 文件，对自由文本中的个人信息进行脱敏，并提供一个预签名下载链接。
导出时，Signals 还会根据这些对话创建 Simulations 模拟场景，因此导出的数据可以直接用于 Evaluations，无需手动准备测试数据。
以下是通过 doctl 执行相同操作的示例，这里筛选的是用户曾纠正 Agent 的会话：
doctl signals export create --agent-id <agent-id> --signal-type MisalignmentCorrection
doctl signals export get <export-id>
doctl signals export download <export-id>
导出文件会保留七天。这个文件可以作为连接后续工作流程的数据交接入口。
从行为信号到更好的 Agent
与人工合成的测试案例相比，被 Signals 标记的生产环境会话往往能提供更有价值的评估案例，因为这些正是 Agent 在真实场景中遇到困难的情况。你可以将这些会话导出为数据集，导入 DigitalOcean Evaluations，使用实际出错的对话来评估新的提示词、工具配置或模型。
你也可以将这些案例作为 Simulations 模拟场景，检查修复方案能否在整个对话过程中持续生效，而不只是改善某一条回复。由于 Signals 也会标记优秀范例，你不仅可以构建包含失败案例的数据集，还可以整理出表现良好的案例，明确什么样的结果值得追求。
对于自行训练模型的团队，这些导出数据还可以用作微调数据，或用于强化学习的奖励数据和偏好数据。
我们正在进一步完善这一闭环，让 Signals 发现的问题能够推动 Agent 的改进方案，并在正式发布之前，使用你自己的评估流程验证这些改动。Signals 将负责监测生产环境中的实际表现。
Signals 的后续规划
Harness Runtime 和 推理引擎 是 Signals 首批支持的数据来源，但并非全部规划。授权机制之后的数据处理管道并不依赖对话的具体来源。
下一步将接入 Action Gateway 的工具调用遥测数据，让受治理的工具调用也能将失败原因和策略执行结果纳入信号分析。Inference Signals 的控制台界面也将在 API 支持之后推出。此外，系统还将支持定时导出，让数据集能够自动刷新，而不必每次都手动发起请求。随着公测期间积累更多使用反馈，Signals 的信号分类体系也会持续扩展。
DigitalOcean Signals 现已开放公测。 你可以为正在运行的 Agent 启用这项功能，并参考 Signals 文档 和 [doctl signals](https://docs.digitalocean.com/reference/doctl/reference/signals/) 命令参考完成配置。
相关产品与选型
