Pipeline 中需要调用数字员工(数据洞察智能体)完成多步推理、知识检索等复杂任务时,使用 agentic-call 节点。该节点对每行数据发起独立对话,支持 Prompt 模板渲染和员工配置。
功能说明
与 llm-call 的区别:llm-call 是一次纯粹的 LLM 推理调用,而 agentic-call 调用用户构建的数字员工。数字员工内部封装了完整的 SOP 分析流程和 Skill 能力,可进行多步骤推理、知识库检索、工具调用等复杂任务。
核心流程:
提取:从输入行中提取
fields指定的字段值。渲染:将字段值填入 Prompt 模板的
{{列名}}占位符,生成完整消息。调用:每行触发一次数字员工的独立对话。
返回:提取对话的纯文本回复,存储为新列。
每行数据独立处理,仅增加新列,不删除原有列,不改变行数。
适用场景
智能分析:调用数字员工对告警、日志、指标进行 SOP 分析和根因定位。
知识问答:基于数字员工的知识库回答业务领域问题。
数据洞察:对每行数据发起独立的智能分析,获取文本洞察。
批量对话:对多行数据并行触发 Agent 调用,批量获取分析结果。
节点配置
以下为 agentic-call 节点的 JSON 配置示例。
{
"id": "node_1",
"type": "agentic-call",
"parameters": {
"prompt": "<Prompt模板或模板引用>",
"fields": "<参与渲染的列名列表>",
"employee": "<数字员工名称>",
"skill": "<技能标识>",
"as": "<输出列名>",
"output": "<输出列列表>"
}
}参数说明
参数 | 类型 | 必填 | 默认值 | 说明 |
| String | 是 | - | Prompt 模板,使用 |
| String | 是 | - | 参与渲染的输入列名,逗号分隔。每个列名必须在 Prompt 中有对应 |
| String | 是 | - | 数字员工名称,如 |
| String | 否 |
| 数字员工技能标识。 |
| String | 否 |
| 输出列名。 |
| String | 否 |
| 节点输出列,逗号分隔。 |
Prompt 编写指南
占位符使用
{{列名}}语法,列名与fields中声明的一致。系统自动校验:Prompt 中的所有
{{列名}}必须在fields中声明,反之亦然。超长 Prompt 建议注册为命名模板,通过
@<path>引用。
模板引用格式:
prompt 值 | 说明 |
| 引用已注册的命名模板。 |
| 内联 Prompt 文本。 |
输入/输出
输入要求
上游节点输出的任意列数据。
要求包含
fields中声明的所有列。
输出列
列名 | 类型 | 来源 | 说明 |
| - | 透传/新增 |
|
| varchar | 新增 | 数字员工的对话回复纯文本。对话失败时为 NULL。 |
行数变化
M → N(M = N):1:1 变换,每行独立触发一次数字员工对话,不增减行数。
效果预览
处理前(3 条):
host_name | metric_name | alert_level |
web-server-01 | cpu_usage | critical |
db-server-02 | disk_io | warning |
app-server-03 | memory | critical |
处理后(3 条):配置 employee = "skill_bench_analysis",prompt = "请分析...",fields = "host_name,metric_name",as = "analysis"。
host_name | metric_name | alert_level | analysis |
web-server-01 | cpu_usage | critical | 经分析,web-server-01 的 CPU 使用率持续超过 95%,根因为... |
db-server-02 | disk_io | warning | db-server-02 的磁盘 IO 出现间歇性峰值,建议检查... |
app-server-03 | memory | critical | app-server-03 内存使用率达到 98%,存在内存泄漏风险... |
行数不变(3 → 3),每行新增 analysis 列,值为数字员工的对话回复文本。
使用示例
示例 1:指标异常分析
{
"id": "n7",
"type": "agentic-call",
"parameters": {
"prompt": "请分析 {{host_name}} 的 {{metric_name}} 指标异常原因",
"fields": "host_name,metric_name",
"employee": "skill_bench_analysis",
"as": "analysis"
}
}调用 skill_bench_analysis 数字员工,对每行告警数据进行根因分析。
示例 2:SOP 知识问答(带技能指定)
{
"id": "n7",
"type": "agentic-call",
"parameters": {
"prompt": "{{question}}",
"fields": "question",
"employee": "apsara-ops",
"skill": "sop",
"as": "answer"
}
}调用 apsara-ops 数字员工的 sop 技能回答业务问题。
示例 3:使用命名模板
{
"id": "n7",
"type": "agentic-call",
"parameters": {
"prompt": "@analysis/alert_diagnosis.md",
"fields": "host_name,metric_name,metric_value",
"employee": "skill_bench_analysis",
"as": "diagnosis"
}
}引用预注册的 Prompt 模板进行分析。
示例 4:完整管道(过滤 → 采样 → 智能体分析)
{
"nodes": [
{ "id": "n1", "type": "project", "parameters": { "host_name": "a", "metric_name": "b", "alert_level": "c", "metric_value": "d" } },
{ "id": "n2", "type": "where", "parameters": { "filter": "alert_level = 'critical'" } },
{ "id": "n3", "type": "sample", "parameters": { "n": 50 } },
{ "id": "n4", "type": "agentic-call", "parameters": { "prompt": "请分析 {{host_name}} 的 {{metric_name}} 指标异常,当前值 {{metric_value}}", "fields": "host_name,metric_name,metric_value", "employee": "skill_bench_analysis", "as": "analysis" } }
]
}先过滤严重告警,再采样控制量,最后调用数字员工逐条分析。
使用建议
性能与成本优化
建议在过滤 + 采样之后使用 agentic-call。数字员工调用延迟高于普通 LLM 调用(涉及多步推理、知识检索),且按调用次数计费,前置降量可大幅减少成本。
推荐管道顺序:过滤 → 采样 →
agentic-call。每行消息创建独立的 Thread 对话,上下文隔离。
技术限制
幂等性:同一输入的数字员工输出不保证完全一致(受模型、知识库版本等影响)。
超时控制:单次请求超时 10 分钟,复杂分析任务需确保 Prompt 精简明确。
最佳实践
员工选择:根据业务场景选择合适的数字员工和技能,不同员工对应不同的知识库和 SOP 流程。
模板复用:超长 Prompt 建议注册为命名模板(
@analysis/alert_diagnosis.md),便于版本管理。结果提取:输出为纯文本(varchar),如需提取结构化数据可配合
extend+regexp_extract或json_parse处理。
边界异常
场景 | 行为 | 排查建议 |
| 校验失败 | 检查节点配置中 |
| 校验失败 | 检查 |
| 校验失败 | 确认已填写数字员工名称,可在数据洞察的数字员工列表中查看可用名称。 |
| 运行时报错 | 核对上游节点的输出列名,确保 |
命名模板( | 运行时报错 | 确认模板路径拼写正确,且已提前注册该命名模板。 |
列值为 NULL | 数字员工可能返回不完整结果 | 在上游使用 |
数字员工对话超时 | 返回 NULL | 精简 Prompt 内容,减少单次对话的分析复杂度。单次请求超时上限为 10 分钟。 |
数字员工不存在 | 返回 NULL | 检查 |