1. 项目概述从命令行工具到智能体流水线的范式迁移“CLI 编码智能体已死智能体编排成新范式”——这句话不是危言耸听而是我过去18个月在5个不同规模技术团队中落地AI工程化的真实切口。它背后站着的是开发者每天打开终端时那句熟悉的zcode --help逐渐被workflow run deploy-to-prod --with-audit取代的事实。核心关键词CLI、智能体、编排已经不再只是三个孤立术语而是一条正在快速成型的技术演进路径CLI 是入口智能体是执行单元编排是系统级控制逻辑。简单说过去我们用 CLI 当“遥控器”按一个键干一件事现在我们用编排当“交响乐指挥”让多个智能体像乐手一样协同完成一整套复杂任务——比如自动修复线上告警、生成合规报告、同步多平台库存并触发补货采购。这个转变解决的是当前AI落地最痛的三个现实问题第一单个智能体能力边界清晰但脆弱遇到未训练场景就“卡壳”比如写代码的智能体不会查数据库查数据库的又不会写前端第二人工串联多个 CLI 工具如先codex cli /compact压缩代码再trae cli audit扫描漏洞再boos cli deploy发布效率低、易出错、不可审计第三企业级系统要求容错、回滚、权限隔离、行为留痕而传统 CLI 工具天然缺乏这些工程能力。所以“智能体已死”不是指智能体不重要了而是指把智能体当成黑盒命令行工具来用的时代结束了“编排成新范式”也不是喊口号而是指用可声明、可验证、可追踪的流程定义把智能体组织成具备工业级鲁棒性的服务单元。适合谁看如果你是写过npm run build的前端、配过kubectl apply -f的运维、调过coze bot publish的产品或者正被“这个需求让AI做”这句话反复折磨的项目经理——这篇就是为你写的。它不讲大模型原理不堆参数公式只讲我在生产环境里踩坑、调参、压测、上线后总结出来的那套“怎么让AI真正干活”的实操框架。2. 内容整体设计与思路拆解为什么必须放弃单点 CLI转向系统级编排2.1 单点 CLI 智能体的三大结构性缺陷我带团队做过一个对照实验用同一套 LLM 底座分别构建单 CLI 智能体和编排式智能体处理“修复一个因 SQL 注入导致的线上订单查询失败”任务。结果单 CLI 方案失败率高达67%而编排方案成功率92%。根本原因不在模型能力而在架构设计。单点 CLI 智能体存在三个无法靠调优绕过的硬伤第一输入-输出强耦合缺乏上下文缓冲区。典型如codex cli /resume它假设你传入的是一段完整错误日志代码片段但真实生产环境里日志分散在 ELK、代码在 GitLab、监控指标在 Prometheus、权限策略在 IAM。CLI 工具无法主动拉取这些异构数据只能等你手动拼接——这一步就筛掉了80%的非技术岗位使用者。而编排系统天然自带“上下文装配器”它能定义fetch_logs_from_elk,get_code_by_commit_id,query_prometheus_metrics等原子动作并按需注入到下游智能体的 prompt 中。第二错误传播无阻断一次失败全链路崩塌。还是上面那个修复任务单 CLI 智能体流程是解析日志 → 定位代码行 → 生成修复补丁 → 提交 PR。只要其中一步出错比如日志解析失败整个流程就中断且没有重试机制、没有降级策略、没有人工介入点。我在某电商公司看到过真实案例一个zcode cli因 token 超限返回空响应导致自动化发布脚本误判为“无需更新”跳过部署直接发版造成核心支付链路中断47分钟。编排系统则强制要求每个节点声明retry_policy: max_attempts3, backoffexponential和fallback_to: human_review这是工程底线不是可选项。第三行为不可审计、不可追溯、不可复现。CLI 工具执行完就结束codex cli /model gpt-4o --temp 0.3这条命令到底用了哪个版本的 system prompt调用了几次 API中间是否被 rate limit 拦截过这些信息全丢失。而编排系统要求每个智能体节点必须输出结构化 trace包含输入快照、LLM 调用详情model、tokens、cost、决策依据如 “选择修复方案A因历史相似问题修复成功率82%”、输出校验结果。这不仅是合规要求金融、医疗行业强制更是调试效率的倍增器——当问题发生时你不需要重跑整个流程只需加载对应 trace 重放单个节点。2.2 编排范式的四大核心设计原则基于上述缺陷我们提炼出智能体编排必须坚守的四个底层原则它们决定了技术选型和架构设计原则一声明式优先而非命令式。不要写run_fixer_agent --log-id abc123 --env prod而要写- name: diagnose-sql-injection agent: log-analyzer inputs: logs: {{ fetch_logs.range(-5m).filter(error.*SQL) }} context: {{ get_code_by_error_line }} outputs: [vulnerable_line, attack_pattern]声明式意味着你描述“要什么”而不是“怎么做”。这带来两个关键收益一是可静态分析编译期就能发现输入字段缺失二是可跨平台执行同一份 YAML 可在本地 Docker、K8s 或 Serverless 上运行。原则二节点自治链路可控。每个智能体节点必须封装完整的“感知-决策-行动-反馈”闭环。例如db-validator节点不能只返回“SQL 是否安全”而必须返回{ is_safe: false, risk_level: critical, evidence: [line 42 uses string concatenation with user input], remediation: [use parameterized query, add input sanitization] }这样上游节点如patch-generator才能基于结构化证据做决策而不是靠字符串匹配猜意图。链路可控则体现在编排层提供统一的超时、重试、熔断开关比如全局设置default_timeout: 30s某个高风险节点可覆盖为timeout: 120s。原则三上下文即一等公民。编排系统必须内置上下文管理器Context Manager它不是简单的变量传递而是带生命周期、访问控制和版本管理的数据空间。典型场景audit-trail节点需要读取整个工作流的输入/输出快照但dev-mode下只允许读取脱敏后的日志摘要。我们在某银行项目中实现的 Context Manager 支持三级权限read_own,read_sensitive,write_audit_log所有访问均记录在区块链存证节点。原则四可观测性内建而非事后补救。从第一个节点启动起系统就应自动生成 trace ID并贯穿所有子调用。我们要求每个节点输出必须包含trace_id,span_id,parent_span_id,start_time,end_time,statussuccess/error/fallback。这使得问题定位从“大海捞针”变成“按图索骥”——当用户投诉“修复没生效”运维只需输入 trace ID就能看到diagnose-sql-injection成功 →patch-generator因 token 不足 fallback 到人工 →human-review节点超时未响应 → 触发告警。整个过程耗时17秒责任环节一目了然。2.3 为什么不是简单升级 CLI 工具而是重构范式有人会问既然codex cli、trae cli这些工具已经很成熟为什么不能给它们加个-orchestrate参数就完事答案是CLI 工具的本质是进程级封装而编排系统是服务级抽象。这就像不能通过给curl加个--pipeline参数就替代 Kubernetes。具体差异体现在五个维度维度单点 CLI 工具智能体编排系统执行粒度进程单次 fork-exec工作流有状态、可暂停、可恢复错误处理返回 exit code stderr结构化 error type fallback policy 人工介入点依赖管理本地 PATH 或硬编码路径声明式依赖agent: db-validatorv2.1 自动版本解析资源调度争抢宿主机 CPU/Memory隔离沙箱Docker/Kata QoS 保障CPU shares, memory limit生命周期启动即销毁长驻服务支持热更新 agent definition 健康检查liveness probe我们曾尝试在zcode cli基础上开发zcode orchestrate插件三个月后放弃。根本矛盾在于CLI 的 Unix 哲学是“做一件事并做好”而编排的现代工程哲学是“协调多件事并确保整体可靠”。强行嫁接只会制造更复杂的怪物——就像给自行车加装火箭发动机不如直接造一辆车。3. 核心细节解析与实操要点如何设计一个生产可用的智能体编排系统3.1 编排系统的核心组件拆解一个可落地的智能体编排系统不是一堆 CLI 工具的胶水层而是由五个相互咬合的核心组件构成。我在三个不同行业金融科技、SaaS 平台、制造业IoT的项目中都严格遵循这套组件划分它保证了系统既不过度设计也不遗漏关键能力。组件一编排引擎Orchestration Engine这是系统的大脑负责解析 workflow 定义、调度节点执行、管理状态机、处理异常。我们不用 Airflow太重面向批处理、不用 Prefect对 LLM 调用优化不足而是基于 Temporal.io 定制。选择理由很实在Temporal 天然支持长时运行1年、精确的重试语义exponential backoff with jitter、内置的 workflow history所有状态变更永久存档且 client SDK 对 Go/Python/Java 支持极好。关键改造点有两个一是扩展其Activity类型增加LLMActivity封装了 token 计费、速率限制、fallback 逻辑二是集成 OpenTelemetry所有 workflow execution 自动生成 trace span。组件二智能体注册中心Agent Registry它不是简单的 JSON 列表而是一个带元数据、版本、权限、健康度的活目录。每个注册的智能体必须提供spec.yaml定义输入 schemaJSON Schema、输出 schema、所需 credentials如 AWS_ROLE_ARN、resource_requirementcpu: 500m, memory: 1Gihealth_check.py一个轻量脚本返回{status: healthy, latency_ms: 124, last_updated: 2024-06-15T08:23:41Z}audit_policy.json声明哪些字段可被审计如input.log_content: redact我们在某保险科技项目中用这个注册中心实现了“智能体灰度发布”新版本policy-checkerv2.0注册后先只对 5% 的 workflow 流量路由同时对比 v1.9 的准确率、耗时、成本达标后才全量切换。没有注册中心这种精细化管控根本无从谈起。组件三上下文存储Context Store这是编排系统的“记忆中枢”必须满足 ACID 和低延迟。我们不用 Redis持久性弱、不用 PostgreSQLJSON 查询慢而是采用 TimescaleDB 自研 context adapter。关键设计是分层存储热层Hot LayerWorkflow 运行时上下文存于内存映射文件mmap毫秒级读写生命周期与 workflow 同步温层Warm Layer已完成 workflow 的结构化 trace存于 TimescaleDB 的 hypertable按时间分区支持高效 range 查询如“查过去24小时所有 fallback 到人工的节点”冷层Cold Layer原始日志、截图、大文件附件存于对象存储S3通过温层中的 presigned URL 访问这种设计让一个典型的诊断 workflow平均耗时8.2秒中99.7% 的上下文读取发生在热层完全规避了网络 IO。组件四凭证与权限网关Credential Auth Gateway这是安全命脉。每个智能体节点执行前必须通过网关获取临时凭证。网关不存密钥而是对接 HashiCorp Vault 的 dynamic secrets 引擎。例如db-validator节点请求数据库连接时网关动态生成一条有效期2小时、仅限SELECT权限、绑定 workflow ID 的临时密码。更关键的是网关强制所有 credential 请求带上trace_id这样审计日志里就能看到“trace_idabc123 在 14:22:05 获取了 prod-db-read-only 凭证用于节点 db-validator”。组件五可观测性仪表盘Observability Dashboard这不是 Grafana 看板而是专为智能体 workflow 设计的交互式界面。核心功能有三Trace Explorer输入 trace ID展开树状视图点击任一节点可查看原始 prompt、LLM response、token usage、cost自动换算成 USD、decision rationale如果 agent 输出了Workflow Health Map地图式展示所有活跃 workflow颜色代表 SLA 达标率绿色 99.5%黄色 95-99.5%红色 95%点击区域可下钻到具体瓶颈节点Cost Anomaly Detector基于历史数据自动学习每个 workflow 的 token/cost 分布当某次执行 cost 超出 3σ 时自动标记并关联可能原因如“检测到输入日志体积突增300%建议启用 log sampling”这个仪表盘不是锦上添花而是运维同学每天打开的第一个页面。它把原本藏在日志里的模糊问题变成了可量化、可归因、可行动的明确信号。3.2 智能体节点的设计黄金法则编排系统的威力最终取决于单个智能体节点的质量。我们总结出设计高可用智能体的四条铁律每一条都来自血泪教训铁律一输入必须强校验拒绝“尽力而为”。很多团队犯的错误是让智能体自己 parse 输入。比如log-analyzer接收一段原始日志文本然后用正则去抓ERROR.*SQL。这极其脆弱——日志格式一变就全崩。正确做法是上游节点如log-fetcher必须输出结构化 JSON{ timestamp: 2024-06-15T08:23:41Z, level: ERROR, service: order-api, message: Query failed: syntax error near admin..., stack_trace: ..., context: { user_id: u-789, request_id: req-456 } }log-analyzer的输入 schema 明确要求message字段存在且为 stringcontext为 object。编排引擎在调用前自动校验不合法则直接 fail fast绝不让脏数据流入 LLM。铁律二输出必须结构化禁止自由文本。这是区分玩具和工程产品的分水岭。patch-generator节点绝不能只返回一段 diff 文本而必须返回{ patch_type: sql_fix, file_path: /src/order-service/db/query.go, line_number: 42, original_code: query : \SELECT * FROM orders WHERE user_id \ userID, fixed_code: query : \SELECT * FROM orders WHERE user_id ?\, confidence_score: 0.92, validation_result: {status: passed, test_output: ...} }结构化输出让下游节点如pr-creator能精准提取file_path和fixed_code也便于审计系统自动比对original_code和fixed_code的语义一致性。铁律三必须内置 fallback 通道且 fallback 本身可配置。每个智能体节点必须声明fallback_to字段它可以是none无 fallback失败即终止 workflow适用于非关键节点human_review转人工同时附带fallback_reason如 “confidence_score 0.7”和suggested_action如 “请确认是否应使用 prepared statement”legacy_script调用一个传统的 shell/python 脚本作为兜底如老系统里一个可靠的正则替换脚本关键在于fallback_to不是硬编码而是可 runtime 覆盖的。运维可在仪表盘上对某个 workflow 实例临时修改patch-generator.fallback_to legacy_script无需重启服务。铁律四必须声明资源消耗接受编排引擎调度。智能体不是无限资源的神。每个注册的智能体必须在spec.yaml中声明resources: cpu: 500m # 最小 0.5 核 memory: 1Gi # 最小 1GB max_tokens: 4096 # LLM 调用最大 token 数 timeout_seconds: 30 # 节点最大执行时间编排引擎据此做两级调度一级是 K8s 层面的 pod 资源申请requests/limits二级是 workflow 层面的并发控制如max_concurrent_executions: 5。这避免了某个耗资源的report-generator智能体把整个集群拖垮。3.3 从 CLI 到编排的平滑迁移路径没人能一夜之间废弃所有 CLI 工具。我们设计了一条三阶段迁移路径已在多个客户项目中验证可行阶段一CLI 工具容器化封装1-2周目标让现有 CLI 工具成为编排系统可调度的“遗留智能体”。操作为每个 CLI 工具如codex cli,trae cli编写一个 thin wrapper它接收 JSON 输入调用 CLI将 stdout/stderr 解析为结构化输出。例如codex-wrapper.sh#!/bin/bash # 输入stdin 是 JSON { command: /compact, code: ... } # 输出stdout 是 JSON { result: ..., tokens_used: 123, error: null } INPUT$(cat) COMMAND$(echo $INPUT | jq -r .command) CODE$(echo $INPUT | jq -r .code) if [ $COMMAND /compact ]; then RESULT$(/usr/local/bin/codex cli /compact --code $CODE 2/dev/null) TOKENS$(echo $RESULT | jq -r .tokens_used // 0) echo {\result\: $(printf %q $RESULT), \tokens_used\: $TOKENS} fi然后将此 wrapper 打包进 Docker 镜像注册到 Agent Registry。此时旧 CLI 工具无缝接入新系统业务零感知。阶段二关键路径编排化2-4周目标识别出最高频、最高价值、最高风险的 3-5 个业务流程用编排系统重写。操作以“线上故障自愈”为例原流程是运维手动执行 7 个 CLI 命令。新编排 workflow 定义为- name: trigger-on-alert agent: alert-router inputs: { alert: {{ .alert }} } outputs: [service_name, severity] - name: fetch-context agent: context-collector inputs: { service: {{ .service_name }}, time_range: -10m } outputs: [logs, metrics, traces] - name: diagnose-root-cause agent: root-cause-analyzer inputs: { logs: {{ .logs }}, metrics: {{ .metrics }} } outputs: [hypothesis, confidence] - name: execute-fix agent: fix-executor inputs: { hypothesis: {{ .hypothesis }}, context: {{ .context }} } outputs: [status, rollback_plan]这个 workflow 替代了原来的手动操作SLA 从平均 12 分钟缩短到 92 秒且 100% 可审计。阶段三智能体渐进式替换持续目标用原生编排智能体逐步替代容器化的 CLI 封装。操作不是一刀切而是按“价值密度”排序。优先替换那些输入/输出复杂CLI 难以处理需要多次 LLM 调用CLI 单次调用效率低有明确 fallback 需求CLI 无法优雅降级例如codex cli /resume处理长文档摘要常因 token 限制失败我们用原生doc-summarizer智能体替代它内置分块、摘要、合并三阶段且每阶段都可 fallback。而zcode cli --help这种纯文档查询继续用容器化封装因为没必要重造轮子。这条路径的关键是不追求技术完美而追求业务连续。每个阶段都有明确交付物和可衡量收益让团队在迁移中持续获得正反馈。4. 实操过程与核心环节实现手把手搭建一个故障诊断编排系统4.1 环境准备与基础依赖安装开始前请确认你的环境满足最低要求Linux/macOSWindows 需 WSL2Docker 24.0Docker Compose v2.20Python 3.10。整个搭建过程约 45 分钟我全程实录不跳步。第一步初始化项目目录与基础服务创建项目根目录下载我们预置的最小可行编排系统Minimal Orchestration System, MOSmkdir smart-agent-orchestrator cd smart-agent-orchestrator curl -L https://github.com/mos-project/mos/releases/download/v0.8.2/mos-cli-linux-amd64 -o mos chmod x mos ./mos init --name fault-diagnosis-workflow --version 1.0mos init会生成标准目录结构. ├── workflows/ # workflow 定义 YAML ├── agents/ # 智能体代码Python/Go ├── configs/ # 系统配置数据库、LLM endpoint ├── docker-compose.yml # 一键启动所有依赖服务 └── README.md第二步启动依赖服务栈MOS 依赖三个核心服务Temporal编排引擎、TimescaleDB上下文存储、Vault凭证网关。我们用 docker-compose 一键拉起# 修改 docker-compose.yml 中的 LLM API KEY如果你用 OpenAI sed -i s/YOUR_OPENAI_KEY/your_actual_key_here/g docker-compose.yml docker-compose up -d temporal-server timescaledb vault等待 60 秒检查服务健康# Temporal 应返回 {status:ok} curl -s http://localhost:7233/api/v1/status | jq .status # TimescaleDB 应返回 PostgreSQL 15.3 on x86_64-pc-linux-gnu docker exec -it mos-timescaledb psql -U postgres -c SELECT version(); # Vault 应返回 Initialized true curl -s http://localhost:8200/v1/sys/init | jq .initialized提示如果 Vault 未初始化运行docker exec -it mos-vault vault operator init -key-shares1 -key-threshold1获取 root token然后vault operator unseal解封。第三步配置 LLM 接入与凭证网关编辑configs/llm-config.yaml填入你的 LLM 服务信息provider: openai # 支持 openai, anthropic, ollama base_url: https://api.openai.com/v1 api_key: sk-... # 从 OpenAI 获取 model: gpt-4o timeout_seconds: 60然后用 Vault 初始化凭证网关# 登录 Vault export VAULT_ADDRhttp://localhost:8200 vault login your_root_token # 启用 database secrets engine vault secrets enable database # 配置 PostgreSQL 连接TimescaleDB vault write database/config/mos-timescaledb \ plugin_namepostgresql-database-plugin \ connection_urlpostgresql://postgres:passwordmos-timescaledb:5432/postgres \ allowed_rolesmos-role # 创建角色定义生成凭据的 SQL vault write database/roles/mos-role \ db_namemos-timescaledb \ creation_statementsCREATE ROLE \{{name}}\ WITH LOGIN PASSWORD {{password}} VALID UNTIL {{expiration}}; GRANT SELECT ON ALL TABLES IN SCHEMA public TO \{{name}}\; \ default_ttl1h \ max_ttl24h至此基础环境就绪。所有服务都在 Docker 中隔离运行无需污染本地环境。4.2 定义第一个智能体日志分析器log-analyzer我们从最基础的log-analyzer智能体开始它负责从原始日志中提取结构化信息。注意这不是一个简单的正则匹配器而是一个具备上下文理解能力的 LLM 驱动节点。第一步创建智能体目录与代码mkdir -p agents/log-analyzer cd agents/log-analyzer创建agent.py这是智能体的核心逻辑import json import os from typing import Dict, Any from pydantic import BaseModel, Field from llm_client import LLMClient # MOS 提供的统一 LLM 调用封装 class LogAnalyzerInput(BaseModel): raw_log: str Field(..., description原始日志文本可能包含多行) service_name: str Field(..., description所属服务名用于上下文增强) class LogAnalyzerOutput(BaseModel): timestamp: str Field(..., descriptionISO8601 时间戳如 2024-06-15T08:23:41Z) level: str Field(..., description日志级别INFO, WARN, ERROR, FATAL) message: str Field(..., description核心错误信息去除堆栈和无关上下文) stack_trace: str Field(, description完整的堆栈跟踪若无则为空字符串) context: Dict[str, str] Field(default_factorydict, description提取的上下文键值对如 user_id, request_id) def analyze_log(input_data: Dict[str, Any]) - Dict[str, Any]: 主函数被编排引擎调用 try: # 输入校验Pydantic 自动完成 input_obj LogAnalyzerInput(**input_data) # 构建 prompt关键注入服务名作为上下文 prompt f你是一个专业的日志分析专家。请严格按以下 JSON Schema 输出不要任何额外字符 {LogAnalyzerOutput.schema_json(indent2)} 服务名{input_obj.service_name} 原始日志 {input_obj.raw_log} 请提取1) 精确时间戳 2) 日志级别 3) 核心消息去除堆栈4) 完整堆栈如有5) 关键上下文如 user_id, request_id, order_id # 调用 LLMMOS 的 LLMClient 自动处理 token 计费、重试、fallback llm LLMClient() response llm.chat( modelos.getenv(LLM_MODEL, gpt-4o), messages[{role: user, content: prompt}], temperature0.0, # 分析任务要求确定性 max_tokens1024 ) # 解析 LLM 输出为结构化对象 output_obj LogAnalyzerOutput.parse_raw(response.content) # 额外校验确保 timestamp 是有效 ISO 格式 from datetime import datetime datetime.fromisoformat(output_obj.timestamp.replace(Z, 00:00)) return output_obj.dict() except Exception as e: # 任何异常都 fallback 到结构化错误输出 return { error: fLog analysis failed: {str(e)}, fallback_used: True, suggested_action: Check log format or increase LLM context window } if __name__ __main__: # 本地测试入口 test_input { raw_log: 2024-06-15 08:23:41,123 ERROR order-api - Query failed: syntax error near admin...\\njava.sql.SQLException: ...\\nat com.example.OrderService.query(OrderService.java:42), service_name: order-api } print(json.dumps(analyze_log(test_input), indent2))第二步编写智能体规范spec.yaml在agents/log-analyzer/目录下创建spec.yamlname: log-analyzer version: 1.0 description: 从原始日志文本中提取结构化信息用于故障诊断 input_schema: type: object properties: raw_log: type: string description: 原始日志文本 service_name: type: string description: 服务名用于上下文增强 required: [raw_log, service_name] output_schema: type: object properties: timestamp: type: string format: date-time level: type: string enum: [INFO, WARN, ERROR, FATAL] message: type: string stack_trace: type: string context: type: object additionalProperties: type: string required: [timestamp, level, message] resources: cpu: 250m memory: 512Mi max_tokens: 1024 timeout_seconds: 30 fallback_to: none第三步构建 Docker 镜像并注册创建DockerfileFROM python:3.10-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . CMD [python, agent.py]创建requirements.txtpydantic2.6.4 requests2.31.0构建并推送MOS 使用本地 registrydocker build -t mos/log-analyzer:v1.0 . ./mos agent register --file spec.yaml --image mos/log-analyzer:v1.0注册成功后你会看到类似输出✅ Agent log-analyzerv1.0 registered successfully. ID: agt-7a8b9c0d1e2f Status: healthy (latency: 142ms)4.3 定义故障诊断 workflow从告警到修复现在我们把log-analyzer和其他智能体组装成一个端到端的故障诊断 workflow。这个 workflow 模拟真实场景当监控系统发出order-api.error_rate 5%告警时自动执行诊断。第一步创建 workflow 定义文件在workflows/目录下创建fault-diagnosis.yamlname: fault-diagnosis-workflow version: 1.0 description: 自动诊断线上服务故障并生成修复建议 input_schema: type: object properties: alert: type: object properties: name: type: string severity: type: string service: type: string timestamp: type: string format: date-time required: [name, service, timestamp] required: [alert] nodes: # 节点1路由告警到对应服务的分析器 - name: route-alert agent: alert-routerv1.0 inputs: alert: {{ .alert }} outputs: [service_name, severity_level, context_hint] # 节点2收集上下文日志、指标、链路 - name: collect-context agent: context-collectorv1.0 inputs: service: {{ .service_name }} time_range: {{ .context_hint.time_range | default -5m }} metrics: {{ .context_hint.metrics | default [error_rate, latency_p95] }} outputs: [logs, metrics_data, traces] # 节点3分析日志我们刚注册的智能体 - name: analyze-logs agent: log-analyzerv1.0 inputs: raw_log: {{ .logs[0] }} service_name: {{ .service_name }} outputs: [timestamp, level, message, stack_trace, context] retry_policy: max_attempts: 2