1. 项目概述这不是玩具是能进生产环境的多智能体系统骨架“DeepAgents MCP A2A Skills”这串词一出来很多人第一反应是——又一个AI圈新造词组合其实不是。它背后是一套正在被真实企业验证、逐步落地的多智能体协同架构范式。我从去年开始在三个不同行业的客户现场推进类似系统一个是制造业的设备故障诊断中台一个是金融风控团队的自动化尽调流水线一个是本地生活平台的商户服务智能调度引擎。它们表面业务差异巨大但底层技术栈高度趋同——核心就是这四个模块的有机咬合DeepAgents作为智能体容器与生命周期管理者MCPModel Communication Protocol作为跨智能体、跨工具、跨语言的统一通信总线A2AAgent-to-Agent定义智能体间协作的契约与编排逻辑而Skills则是可插拔、可复用、可灰度发布的原子能力单元。它不是LangChain里跑个demo的玩具框架也不是只支持单次推理的静态Agent链它是面向7×24小时运行、支持千级并发请求、具备服务熔断与降级能力、能对接ERP/CRM/工单系统等传统IT资产的企业级底座。关键词里的“superpower skills”“蓝湖mcp”“playwright mcp”“burpsuite mcp”本质上都是这个架构下Skills层的具体落地产物——前端工程师用蓝湖MCP把设计稿自动转成React组件安全工程师用Burp Suite MCP让AI自动执行渗透测试流程测试工程师用Playwright MCP驱动浏览器完成全链路回归验证。整套体系的真正价值不在于某个Agent多聪明而在于它能把“人写代码”“人点鼠标”“人填表单”这些动作全部翻译成标准化、可编排、可审计、可回滚的Skills调用。你不需要从零造轮子但必须理解每个齿轮怎么咬合、哪里会打滑、润滑剂该加在哪。2. 架构设计与选型逻辑为什么是这四块拼图而不是别的2.1 DeepAgents不是LangChain Agent的简单封装而是智能体OS很多人看到DeepAgents下意识对标LangChain的AgentExecutor或LlamaIndex的ReActAgent。这是典型误区。DeepAgents的设计初衷是解决LangChain生态长期存在的三个硬伤状态不可控、生命周期不可管、错误不可追溯。LangChain的Agent本质是函数式调用链一次run()执行完就销毁中间状态全靠LLM记忆维持一旦出错连“刚才调用了哪个Tool”都查不到日志。而DeepAgents强制引入了**智能体实例Agent Instance**概念——每个Agent启动时系统分配唯一ID、绑定专属内存空间含短期记忆Buffer和长期知识索引、挂载独立资源配额CPU/内存/Token限额并注册到中央Agent Registry。这意味着你可以像管理K8s Pod一样管理Agent查看实时CPU占用、强制Kill卡死实例、对特定Agent做灰度升级、甚至为高优先级任务预留专用Agent池。我们给某银行做的反洗钱模型校验系统就依赖这套机制当监管新规下发系统自动拉起50个DeepAgents实例并行校验历史交易每个实例只处理1万条记录超时30秒自动终止并移交备用队列全程无单点故障。DeepAgents的底层不是Python函数而是基于Rust写的轻量级运行时类似WASI支持WebAssembly沙箱隔离确保第三方Skills代码无法越权访问宿主文件系统。这点在金融、医疗等强合规场景是刚需——你绝不能允许一个从GitHub下载的“数学建模Skills”直接读取数据库连接字符串。2.2 MCP协议即胶水不是API是语义层统一总线MCPModel Communication Protocol常被误读为“另一个REST API标准”。大错特错。它的核心价值不在传输格式而在语义抽象层。传统API调用是“我要调用XX接口传参数A、B、C”而MCP要求所有Skills必须声明自己的能力契约Capability Contract包括输入SchemaJSON Schema、输出Schema、副作用声明是否修改数据是否触发外部事件、资源消耗预估预计耗时/Token/内存、失败重试策略。比如一个“生成财报摘要”的Skills其MCP契约会明确写出{ input: { type: object, properties: { quarter: {enum: [Q1,Q2,Q3,Q4]}, company_id: {type: string} } }, output: { type: object, properties: { summary: {type: string}, risk_score: {type: number} } }, side_effects: [read:financial_db, write:report_cache], resource_estimate: { cpu_ms: 1200, token_cost: 850 } }这个契约让DeepAgents能在调用前做静态分析发现该Skills需要读取财务数据库就自动注入带RBAC权限的DB连接池发现其副作用包含写缓存就提前开启分布式事务上下文。更关键的是MCP让不同语言实现的Skills能无缝协作——Python写的“Excel解析Skills”、Go写的“邮件发送Skills”、Rust写的“PDF签名Skills”只要遵守同一份MCP契约就能被同一个Agent编排调用。我们实测过用MCP协议一个由TypeScript写的前端组件Skills负责渲染图表能被Python Agent调用再把结果传给Java写的风控规则引擎Skills全程无需任何适配层。这种跨语言、跨进程、跨网络的语义互通能力才是MCP区别于普通API网关的本质。2.3 A2A协作不是链式调用是状态机驱动的契约履约A2AAgent-to-Agent常被简化为“Agent A调用Agent B”。但真实企业场景中协作远比这复杂。比如电商大促期间的库存协调订单Agent发现库存不足不能简单调用“补货Agent”而要触发一套多阶段协商流程——先向采购Agent发起询价请求等待报价后同步给财务Agent评估预算三方达成一致再通知仓储Agent执行调拨。这个过程涉及超时、拒绝、反悔、状态回滚等复杂逻辑。A2A正是为此设计它把Agent间协作建模为可编程状态机Programmable State Machine。每个协作流程定义为一个A2A Workflow包含状态节点如“询价中”“预算审批中”“已确认”、转换条件如“采购Agent返回报价且价格阈值”、超时策略“询价超时自动降级为紧急采购通道”、错误处理分支“财务Agent拒绝预算触发替代方案启用预售模式”。Workflow本身是YAML描述可版本化管理、可热更新、可AB测试。我们在某快消品牌落地时把新品上市流程拆解为12个A2A Workflow覆盖市场部、供应链、IT、法务等7个部门的Agent协作。最关键是A2A不依赖中心化调度器——每个Agent本地运行Workflow Engine通过MCP广播状态变更天然支持去中心化部署。当某个区域数据中心宕机对应Agent自动切换到备用Workflow实例其他Agent感知到状态变更后继续履约整个流程无感降级。2.4 Skills不是函数库是带SLA承诺的微服务把Skills理解为“AI调用的函数”是危险的。在企业级系统中Skills必须具备服务等级协议SLA承诺能力。一个合格的Skills至少要提供三类保障可用性承诺99.95% uptime支持健康检查端点/healthz和优雅下线/shutdown性能承诺P95响应时间≤800ms支持并发限流令牌桶算法安全承诺输入输出自动脱敏如身份证号自动替换为***支持OAuth2.0鉴权调用链路全埋点。我们曾遇到一个典型反面案例某团队用开源的“股票分析Skills”结果因未做输入校验被恶意构造的JSON导致内存溢出拖垮整个Agent集群。后来我们强制推行Skills SDK规范所有Skills必须继承BaseSkill类自动注入日志追踪ID、自动捕获异常、自动上报性能指标。更重要的是Skills必须声明自己的能力边界Capability Boundary——比如“天气查询Skills”只能访问公开API不能读取内部气象站数据“合同审核Skills”只能解析PDF文本不能调用OCR服务。这个边界由MCP网关在运行时强制拦截而非靠开发者自觉。现在我们交付的Skills90%以上都通过了自动化SLA测试套件模拟1000并发请求验证P95延迟、错误率、资源泄漏等指标。这才是企业敢把核心业务交给AI Skills的前提。3. 实战搭建全流程从零开始部署一个可运行的订单履约Agent3.1 环境准备与依赖安装避开Docker镜像的坑别急着docker-compose up。企业环境往往禁用Docker Desktop且要求所有组件通过内部镜像仓库分发。我们实际部署时采用二进制分发配置中心驱动模式DeepAgents Runtime从官方GitHub Release下载deepagents-v2.3.1-linux-amd64.tar.gz解压后得到deepagentsd二进制文件。注意不要用apt install deepagents官方APT源已停更旧版存在CVE-2023-XXXX漏洞MCP Server使用Go编译的mcp-server而非Node.js版后者在高并发下内存泄漏严重。编译命令CGO_ENABLED0 go build -a -ldflags -s -w -o mcp-server ./cmd/serverSkills Registry选用轻量级SQLite替代PostgreSQL除非你真有百万级Skills。关键配置项[storage] type sqlite path /var/lib/deepagents/skills.db # 启用WAL模式提升并发写入性能 sqlite_wal trueAgent Config Center用Consul而非EtcdConsul的KV存储健康检查ACL策略更贴合企业需求。特别注意DeepAgents默认从http://localhost:8500/v1/kv/deepagents/config拉取配置需提前在Consul中写入curl -X PUT -d {mcp_endpoint:http://mcp-server:8080,skills_registry:sqlite:///var/lib/deepagents/skills.db} \ http://consul:8500/v1/kv/deepagents/config提示首次启动时DeepAgents会尝试连接Consul若超时3秒则fallback到本地config.yaml。务必在config.yaml中设置fallback_mode true避免网络抖动导致Agent启动失败。3.2 Skills开发实战以“物流轨迹查询”为例我们以电商场景最常用的“物流轨迹查询”Skills为例展示如何写出符合企业级要求的Skills。它需对接菜鸟、顺丰、京东三家API但对外暴露统一MCP契约。Step 1定义MCP契约contract.yamlname: logistics-tracker version: 1.2.0 input: type: object properties: tracking_number: type: string pattern: ^[A-Za-z0-9]{12,20}$ # 正则校验运单号格式 carrier: type: string enum: [sf, cainiao, jd] required: [tracking_number, carrier] output: type: object properties: status: type: string enum: [delivered, in_transit, pending, failed] steps: type: array items: type: object properties: time: { type: string, format: date-time } location: { type: string } remark: { type: string } side_effects: [read:logistics_api] resource_estimate: cpu_ms: 450 token_cost: 220Step 2实现SkillsPythonfrom deepagents.skills import BaseSkill import requests from urllib.parse import quote class LogisticsTracker(BaseSkill): def __init__(self): super().__init__() # 从配置中心加载API密钥而非硬编码 self.api_keys self.config.get(logistics_api_keys, {}) def execute(self, input_data: dict) - dict: # 1. 输入校验自动触发contract.yaml中的pattern校验 self.validate_input(input_data) # 2. 根据carrier选择API carrier input_data[carrier] if carrier sf: return self._query_sf(input_data[tracking_number]) elif carrier cainiao: return self._query_cainiao(input_data[tracking_number]) else: return self._query_jd(input_data[tracking_number]) def _query_sf(self, tn: str) - dict: # 关键添加熔断器防止顺丰API雪崩 with self.circuit_breaker(namesf_api, failure_threshold5, timeout30): resp requests.get( fhttps://api.sf-express.com/track?tn{quote(tn)}, headers{Authorization: fBearer {self.api_keys[sf]}}, timeout5 ) resp.raise_for_status() data resp.json() # 3. 输出校验确保返回结构符合contract.yaml return self.validate_output({ status: self._map_sf_status(data[status]), steps: [{time: s[time], location: s[location], remark: s[remark]} for s in data.get(steps, [])] }) def _map_sf_status(self, sf_status: str) - str: mapping {DELIVERED: delivered, TRANSIT: in_transit} return mapping.get(sf_status, pending) # 注册Skills自动加载contract.yaml if __name__ __main__: LogisticsTracker().serve()Step 3打包与注册# 生成Skills包含contract.yaml和代码 zip -r logistics-tracker-1.2.0.zip contract.yaml logistics_tracker.py # 通过MCP CLI注册到Registry mcp-cli skills register --file logistics-tracker-1.2.0.zip \ --endpoint http://mcp-server:8080 \ --token $MCP_TOKEN注意mcp-cli会自动校验contract.yaml语法、验证代码可执行性、扫描安全漏洞如requests未设timeout。若校验失败注册直接拒绝杜绝“带病上线”。3.3 DeepAgents配置与Agent定义让订单Agent学会“多线程思考”订单履约Agent不是单个大模型而是多个专业化子Agent的协同体。我们定义三个子Agentorder-validator校验订单合法性库存、地址、支付状态logistics-coordinator调用物流Skills协调多承运商customer-notifier生成个性化通知文案并推送。Agent配置文件order-agent.yamlname: order-fufillment-agent version: 1.0.0 # 每个子Agent独立配置避免单点故障 subagents: - name: order-validator model: qwen2-7b-instruct # 小模型专注规则判断省成本 memory_limit: 512MB timeout: 15s - name: logistics-coordinator model: deepseek-v2-16b # 大模型处理复杂物流决策 memory_limit: 2GB timeout: 60s - name: customer-notifier model: gemma-2b-it # 轻量模型生成文案 memory_limit: 256MB timeout: 10s # A2A协作流程定义 a2a_workflows: - name: fulfill-order initial_state: validate-order states: - name: validate-order on_enter: call:order-validator.validate transitions: - condition: output.status valid target: coordinate-logistics - condition: output.status invalid target: reject-order - name: coordinate-logistics on_enter: call:logistics-coordinator.plan_route transitions: - condition: output.route_confirmed true target: notify-customer - name: notify-customer on_enter: call:customer-notifier.send_message transitions: - target: done timeout: 120s # 整个流程超时2分钟启动命令deepagentsd start --config order-agent.yaml \ --registry http://consul:8500 \ --mcp-endpoint http://mcp-server:8080实操心得子Agent的model选择有讲究。我们测试过用Qwen2-7B做订单校验准确率99.2%耗时平均2.3秒若用DeepSeek-V2-16B准确率仅提升0.3%但耗时增至8.7秒Token成本翻4倍。企业级系统必须做这种“精度-成本-时延”三角权衡。3.4 MCP Server高级配置让协议总线扛住大促流量MCP Server不是开箱即用的玩具。大促期间每秒数千次Skills调用必须针对性优化连接池调优默认HTTP连接池仅100个连接需改为[http] max_idle_conns 2000 max_idle_conns_per_host 1000 idle_conn_timeout 30s熔断与限流为每个Skills配置独立熔断器[skills.logistics-tracker] circuit_breaker: failure_threshold 10 timeout 60s half_open_after 300s rate_limiter: tokens_per_second 100 burst 500缓存策略对幂等Skills启用响应缓存如物流查询[skills.logistics-tracker.cache] enabled true ttl 300s # 5分钟缓存 key_template {{.input.tracking_number}}-{{.input.carrier}}审计日志所有Skills调用必须记录到ELK[audit] enabled true endpoint http://elk:9200/deepagents-audit/_doc # 日志字段脱敏隐藏tracking_number明文只存hash redact_fields [input.tracking_number]我们曾在线上环境实测未优化前MCP Server在2000 QPS下出现连接超时启用上述配置后稳定支撑5000 QPSP99延迟保持在120ms内。4. 常见问题与排查技巧实录那些文档里不会写的坑4.1 Skills调用失败但日志空白检查MCP网关的“静默丢弃”机制现象某个Skills明明注册成功但Agent调用时返回{error: skill not found}而MCP Server日志里却没有任何记录。根因MCP网关默认启用静默丢弃模式Silent Drop——当Skills的输入校验失败如运单号格式不符网关直接返回400错误且不记录到access log避免日志爆炸。排查步骤查看MCP Server的debug.log非access.logtail -f /var/log/mcp/debug.log | grep logistics-tracker若看到input validation failed: tracking_number does not match pattern说明是输入校验失败临时关闭静默丢弃在MCP配置中添加[logging] silent_drop false重启后即可在access.log看到完整错误详情。经验生产环境切勿长期关闭静默丢弃建议用Prometheus监控mcp_skill_validation_errors_total{skilllogistics-tracker}指标当该指标突增时自动告警并触发输入格式检查。4.2 Agent内存持续增长直至OOM警惕LLM上下文的“幽灵引用”现象DeepAgents运行数小时后RSS内存从500MB涨到3GBpstack显示大量Python线程卡在llama_cpp.llama_eval。根因DeepAgents的默认上下文管理器存在引用泄漏——当Agent处理长对话时历史消息对象被LLM推理线程意外持有GC无法回收。解决方案升级至DeepAgents v2.3.1修复了ContextManager.__del__未释放LLM句柄的bug强制设置上下文长度上限在Agent配置中添加max_context_length: 4096对长文本处理改用流式分块# 错误一次性加载10MB日志文件 full_log open(app.log).read() agent.invoke({log: full_log}) # 正确分块处理每块不超过2048token for chunk in split_by_token(full_log, 2048): result agent.invoke({log_chunk: chunk}) # 立即处理result避免累积我们曾因此问题导致某客户生产环境每日重启3次升级后稳定运行47天无OOM。4.3 A2A Workflow卡在某个状态不动检查跨Agent的时钟漂移现象A2A Workflow在“budget-approval”状态停滞deepagentsctl list workflows显示状态未更新但财务Agent日志显示已返回审批结果。根因不同Agent部署在不同物理机NTP时间不同步超过5秒导致Workflow Engine的state_timeout判定失效Engine认为“审批超时”而财务Agent认为“刚返回结果”。验证方法# 在所有Agent节点执行 ntpstat # 若显示unsynchronised或offset 100ms即存在漂移修复方案所有节点强制使用同一NTP服务器sudo systemctl stop systemd-timesyncd sudo ntpdate -s 192.168.1.100在DeepAgents配置中启用时钟校验a2a: clock_drift_tolerance: 2s # 允许最大2秒漂移 sync_clock_on_start: true # 启动时强制校准注意云厂商的NTP服务如AWS Time Sync虽稳定但跨可用区节点间仍可能有毫秒级漂移企业私有云必须自建NTP集群。4.4 MCP调用返回503 Service Unavailable不是服务宕机是Skills的健康检查失败现象MCP Server返回503但curl http://mcp-server:8080/healthz显示OKSkills进程也正常运行。根因MCP Server对每个Skills执行主动健康检查GET/healthz若Skills的/healthz返回非200或响应超时默认2秒MCP Server会将其标记为DOWN并拒绝路由请求。排查清单检查项命令预期结果Skills健康端点是否可达curl -v http://logistics-skills:8000/healthzHTTP/1.1 200 OKSkills健康检查是否超时time curl -o /dev/null -s -w %{http_code} http://logistics-skills:8000/healthz响应时间 1.5sSkills是否正确设置HTTP Keep-Alivecurl -I http://logistics-skills:8000/healthz | grep ConnectionConnection: keep-alive我们遇到过最隐蔽的案例某Skills用Flask开发未设置app.config[SEND_FILE_MAX_AGE_DEFAULT] 0导致健康检查响应被CDN缓存MCP Server反复收到过期的200响应而实际Skills已崩溃。解决方案健康检查端点必须禁用所有缓存头。4.5 如何快速定位Skills性能瓶颈用MCP的“火焰图”功能MCP Server内置性能分析器无需额外APM工具启用性能采集mcp-server --profile-enable --profile-port 6060触发慢速Skills调用访问http://mcp-server:6060/debug/pprof/下载profile文件用go tool pprof -http:8080 profile生成火焰图。火焰图中重点关注http.(*ServeMux).ServeHTTP下的skills.execute耗时若skills.execute下database/sql.(*DB).Query占比高说明SQL未优化若skills.execute下runtime.mallocgc占比高说明Skills存在内存分配风暴如频繁创建大对象。我们曾用此方法发现一个“生成报表”Skills每次调用创建10万个临时字典对象将P95延迟从200ms拉高到2.3秒。重构为对象池复用后延迟降至180ms。5. Skills生态建设从单点能力到可复用技能市场的关键跃迁5.1 内部Skills市场让业务部门自己上架“合同审核”Skills企业最大的误区是把Skills开发全权交给AI团队。我们推动某律所客户建立内部Skills市场让资深律师用低代码方式上架Skills律师填写表单输入“合同类型”采购/租赁/雇佣、“审核要点”付款条款/违约责任/管辖法院、“风险等级”高/中/低系统自动生成MCP契约和Python模板律师只需粘贴正则表达式如r付款方式(.?)提取付款方式和风险判断逻辑如if 预付款 in payment_terms: risk high点击“发布”系统自动打包、签名、注册到MCP Registry。效果3个月内业务部门自主上架47个Skills覆盖80%常规合同类型AI团队从“写代码”转向“审核契约合规性”和“性能基线测试”。5.2 Skills版本管理灰度发布与AB测试的实操细节Skills不是静态文件必须支持热更新。我们采用双版本路由Dual-Version Routing每个Skills注册时指定primary_version如1.2.0和shadow_version如1.3.0-betaMCP Server按权重分流90%流量到1.2.010%到1.3.0-beta监控mcp_skill_response_time_seconds_bucket{version1.3.0-beta}指标若P95延迟优于1.2.0且错误率0.1%自动提升为primary。关键配置[skills.contract-review] primary_version 1.2.0 shadow_version 1.3.0-beta shadow_weight 0.1 # 10%流量 # 自动升级条件 auto_promote: latency_improvement: 0.2 # P95降低20% error_rate_threshold: 0.001实操心得灰度期间必须开启“影子模式Shadow Mode”——1.3.0-beta的输出不返回给Agent只用于指标对比。避免新版本Bug影响线上业务。5.3 Skills安全审计从代码扫描到运行时防护的三层防线Skills安全不能只靠开发自觉。我们构建三层防护静态扫描层CI流水线集成Semgrep检测硬编码密钥、危险函数eval()、os.system()、未校验输入动态沙箱层Skills运行在Firecracker MicroVM中限制网络仅允许访问白名单域名api.legaltech.com文件只读挂载/etc/skills-config禁止写入系统调用禁用execve、openat等高危syscall运行时防护层MCP网关注入eBPF探针实时监控进程创建拦截fork()/clone()调用内存分配当单次malloc1MB时记录堆栈并告警网络连接记录所有DNS查询发现非常规域名如xxx-malware.ru立即阻断。某次审计中我们发现一个从GitHub引入的“PDF解析Skills”其依赖包pdf-parser-2.1.0包含恶意后门会在解析时外连C2服务器。三层防护中静态扫描未发现后门代码混淆但eBPF探针在测试环境捕获到异常DNS请求及时拦截。5.4 Skills性能基线库避免“越优化越慢”的陷阱很多团队陷入误区不断给Skills加缓存、加索引、加异步结果P95延迟反而上升。根源在于缺乏性能基线。我们建立Skills性能基线库每个Skills注册时必须提交基准测试报告benchmark.json{ version: 1.2.0, test_cases: [ { name: small-input, input: {text: Hello}, p95_ms: 120, p99_ms: 180 }, { name: large-input, input: {text: ... }, p95_ms: 450, p99_ms: 620 } ] }MCP Server启动时自动加载基线库当Skills新版本注册强制运行基准测试若p95_ms恶化10%拒绝上线。我们曾因此拦截一个“文本摘要Skills”的升级新版本用更大模型P50提升但P99恶化35%不符合SLA。最终采用模型蒸馏方案在P99不变前提下提升P50。6. 生产环境运维手册让多智能体系统像数据库一样可靠6.1 深度监控指标体系不止看CPU要看“智能体健康度”传统监控只看CPU、内存、HTTP状态码。DeepAgents需要专属指标deepagents_agent_active_count{agentorder-fufillment}活跃Agent实例数突降说明实例崩溃deepagents_subagent_queue_length{subagentlogistics-coordinator}子Agent任务队列长度持续100说明处理不过来mcp_skill_call_duration_seconds_bucket{skilllogistics-tracker,le0.5}500ms内完成率低于95%需告警a2a_workflow_state_duration_seconds{workflowfulfill-order,statecoordinate-logistics}各状态停留时间某状态超时说明协作卡点。告警规则示例Prometheus# 子Agent队列堆积告警 deepagents_subagent_queue_length 200 and rate(deepagents_subagent_queue_length[5m]) 0 # A2A流程卡顿告警 a2a_workflow_state_duration_seconds{statebudget-approval} 3006.2 故障自愈机制当物流Skills宕机时自动降级到人工通道MCP Server支持策略化降级Policy-based Fallback[skills.logistics-tracker] fallback: # 一级降级调用备用API如中通API primary: sf-api secondary: zto-api # 二级降级触发人工工单 tertiary: type: ticket system: jira project: LOGISTICS summary: 物流查询失败{{.input.tracking_number}} description: Carrier: {{.input.carrier}}, Error: {{.error}}当SF API连续5次失败MCP Server自动切换到中通API若中通也失败则创建Jira工单并返回用户“物流信息暂不可查客服将在30分钟内联系您”。这种降级不是简单返回错误而是业务连续性的保障。6.3 容灾演练脚本每月一次“杀死一半Agent”的实战检验我们编写容灾演练脚本disaster-drill.sh#!/bin/bash # 1. 随机选择50% Agent实例 AGENT_IDS$(deepagentsctl list agents --format json | jq -r .[] | select(.statusrunning) | .id | shuf -n 50) # 2. 强制Kill模拟节点宕机 for id in $AGENT_IDS; do deepagentsctl kill $id done # 3. 等待30秒检查A2A Workflow自动迁移 sleep 30 FAILED_WORKFLOWS$(deepagentsctl list workflows --status failed | wc -l) if [ $FAILED_WORKFLOWS -gt 0 ]; then echo ERROR: $FAILED_WORKFLO
