SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场investigating-agentforce-d360

investigating-agentforce-d360

数据与分析

查看项目

更新于 10-14 21:58

技能介绍

用途

investigating-agentforce-d360 用于从 Data Cloud 中重建单个 Agentforce 会话的 360° 视图。它读取 Data Cloud 已物化的运行时审计行（STDM + GenAI DMO），按层级重建会话，并渲染为人类可读的摘要。典型约 15 轮会话的墙钟时间约为 10–30 秒。

该流水线仅基于 Data Cloud（DC-only），不是运行时可用性工具。

主要能力

  • 会话发现：在用户没有会话 id 时，可依据时间范围、智能体、渠道、结束结果或对话文本片段查找匹配会话，并以编号列表呈现供选择。
  • 会话解析：接受 Agent Session UUID 或 MessagingSession id（0Mw 前缀）。0Mw id 通过 resolve_session.py 解析，首次获取时进行实时 DC 查询，之后优先使用磁盘缓存。一个 MessagingSession id 可能映射到多个 Agent Session UUID，多匹配时会打印所有候选并以非零状态退出。
  • 三阶段流水线：fetch_dc.py 执行 DC Query REST 瀑布（5 波），产出 24 个 dc.<name>.json 及 dc._session_manifest.json；assemble_dc.py 进行纯内存层级连接，产出 dc._session_tree.json；render_dc.py 产出多段人类摘要 dc._session_summary.md。各阶段可独立运行。
  • 渲染摘要包含：会话身份、会话引导、ID 参考、对话记录、完整层级追踪（Interaction → Step → Generation → GatewayRequest，含 +start + duration = +end 计算）、每轮摘要、规划器 LLM 调用（需 --show-prompts，默认抑制）、可视化分析（甘特图 + LLM 调用叠加）、会话计数、空数据诊断、会话过滤后的目录。
  • 审计完整性：检查 GatewayRequest 与 GatewayResponse 的 1:1 不变量，漂移会在 counts.audit_chain_1to1_ok 中标记。

使用方式

前置条件：已认证目标组织的 sf CLI（sf org login web --alias <alias>）、目标组织已启用 Data Cloud 且 STDM + GenAI DMO 已物化、Python 3.10+。

脚本前缀解析：

prefix="${SKILL_ROOT:-${PLUGIN_ROOT:-$HOME/.vibe/skills}/investigating-agentforce-d360}/scripts"

会话发现：

python3 "$prefix/discover_sessions.py" --org <alias> [filters...]

过滤器（除 --org 外均可选）：--since <expr>（默认最近 24 小时，接受 "last 2 hours"、"today"、ISO 日期）、--agent <api-name>、--channel <Messaging|Builder|Voice>、--outcome <USER_ENDED|ESCALATED|TRANSFERRED|TIMEOUT|NOT_SET>、--grep <substring>、--tz <IANA>、--limit <N>（默认 20）。

完整流水线调用：

python3 "$prefix/fetch_dc.py" --session <session-id-or-messaging-id> --org <alias>

标志：--verbose 显示每个 DMO 的行数；--no-assemble / --no-render 可提前停止。所有入口脚本（fetch_dc.py、assemble_dc.py、render_dc.py、resolve_session.py、discover_sessions.py）均接受 --data-dir <path> 和 --cache-dir <path> 覆盖默认的 ~/.vibe/{data,cache}/investigating-agentforce-d360/ 根目录。

产物默认落在 ~/.vibe/data/investigating-agentforce-d360/<org_id15>/<agent><ver>/<session_id>/。messaging id 仅作为查找键，从不作为目录名。主导智能体（sorted(agents_observed) 中的第一个）命名 <agent><ver>/ 段。

适用场景

  • 追踪指定会话："Trace session <uuid> in my-org" → fetch_dc.py --session <uuid> --org my-org → assemble → render。
  • 总结指定 MessagingSession："Summarize what happened in 0Mw…" → 解析为 UUID，再走完整 DC 流水线。
  • 查找特定会话："Find escalated sessions today in my-org on Messaging" → discover_sessions.py --since today --outcome ESCALATED --channel Messaging，打印选择器，用户选择后走 DC 流水线。
  • 逐步讲解会话："Walk me through this session" → 同追踪，自上而下阅读渲染摘要。

DC 擅长回答：运行了什么（每个步骤、每次 LLM 调用、每个网关请求与响应，含时间戳与时长）；用户看到了什么（完整消息记录）；LLM 产出了什么（生成内容、token 计数、信任分数）；工具调用（操作调用、输入、输出、错误）；反馈与标记；审计完整性。

限制

  • DC-only 盲区：DC 只能回答“发生了什么”，不能回答“本可能发生但未发生”的情况，例如某轮分类器有哪些主题可用、某主题声明了哪些操作与哪些实际提供给 LLM、LLM 为何选择某主题/操作。若用户问题涉及为何某主题或操作被或未被使用，DC-only 几乎总是不够，应告知用户需要该轮的运行时规划器追踪，不要从仅运行时证据编造根因。
  • gateway_requests_dropped_by_stdm：当 DC 报告零 gateway_requests 行但运行时遥测显示 LLM 调用确实触发时，该技能无法确定区分“STDM 导出器丢弃写入”与“源头确实禁用了日志”。会话会报告为 planner_ran_no_gateway_logs，操作员可检查平台遥测以区分。
  • 延迟：Generation 与 GatewayRequest 携带单次写入时间戳，而非开始/结束对。渲染器不计算它们之间的“延迟”——该差值反映 DC 的序列化顺序，而非 LLM 调用耗时。
  • Data Cloud 物化延迟：新会话可能显示 interactions_not_materialized_yet，若 STDM 尚未跟上，可等一两分钟后重跑。
  • 零行查询会在 manifest 中记录 status: empty，不写文件；assemble_dc 容忍缺失文件。

产物

24 个 dc.<name>.json（sessions、steps、gateway_requests、interactions、messages、gateway_responses、participants、generations、gateway_request_llm、content_quality、content_category、gateway_request_metadata、tags、tag_definitions、gateway_request_tags、tag_associations、tag_definition_associations、feedback、feedback_details、gateway_records、moments、moment_interactions、telemetry_spans、app_generation），以及 dc._session_manifest.json（每 DMO 行数 + 空数据）、dc._session_tree.json（层级连接）、dc._session_summary.md（渲染摘要）。

深入分析可打开 dc._session_tree.json，它是摘要渲染的唯一事实来源。完整流水线契约见 references/dc_pipeline_contract.md，每 DMO 字段参考见 references/dc_dmo_fields.md，完整读取顺序见 references/artifacts.md。