AI Agent Runtime：从LLM调用到生产级运行时的四层演进

1. 这不是“选框架”，而是重新定义你和大模型打交道的方式

“AI Agent 架构怎么选？”——这句话最近在技术群、内部分享会、甚至简历筛选环节里高频出现，但绝大多数人问完就去翻文档、看GitHub star数、比对LangChain和LlamaIndex的API差异。我见过太多团队花三周搭好LangChain流水线，结果在真实业务场景里卡死在“工具调用失败不重试”“记忆状态跨轮次丢失”“错误提示全是token截断后的乱码”这种基础问题上。这不是框架不好，是大家从一开始就没搞清：AI Agent 不是 LLM 的包装壳，而是一套全新的运行时契约（Runtime Contract）。它要解决的根本问题，不是“怎么调一次大模型”，而是“当用户说‘帮我把上周销售数据按区域汇总成PPT发给王总’时，系统如何拆解、调度、容错、回溯、审计，并在2分钟内交付一个可验证的结果”。这背后牵扯的是任务编排引擎、状态持久化策略、工具注册与沙箱隔离、可观测性埋点、以及最关键的——LLM输出结构化的稳定性保障。所以本文不谈“哪个库更火”，只讲我在三个不同规模项目中踩出来的路：第一个是单机脚本级Agent，靠prompt engineering硬扛；第二个是微服务化Agent平台，引入了轻量级Harness Runtime；第三个是支撑日均50万次调用的生产级系统，最终落地为一套可插拔、可灰度、可审计的Runtime内核。所有方案都基于开源可复现组件，没有黑盒，没有魔改，只有参数、配置、和实测数据。如果你正被“Agent跑不通”“效果不稳定”“上线后不敢关监控”困扰，这篇就是为你写的。

2. 从一次LLM调用到完整Runtime：四层架构演进的真实动因

2.1 第一层：裸调LLM——为什么连“重试”都要自己手写？

最原始的Agent形态，就是直接调用OpenAI或本地部署的vLLM接口。比如用Python写个函数：

import openai def simple_agent(query): response = openai.ChatCompletion.create( model="gpt-4-turbo", messages=[{"role": "user", "content": query}], temperature=0.3 ) return response.choices[0].message.content

看起来干净利落，但实际一上线就暴露问题。某次我们让Agent生成会议纪要，输入是12页PDF的OCR文本（约8000 token），结果API返回429 Too Many Requests。按常规思路，加个time.sleep(1)就行？不行。因为OpenAI的限流是按每分钟请求数+每分钟token数双维度计算的，sleep 1秒只能缓解请求频次，对token超限毫无作用。我们实测发现，当单次请求token超过6000时，即使QPS压到0.5，仍有37%概率触发429。解决方案只能是：预估输入token，超限时主动分块、摘要、再拼接。但这已经不是“调用LLM”，而是开始构建前置预处理管道了。

提示：裸调LLM最大的陷阱，是把所有异常都当成“网络问题”。实际上，500 Internal Error可能是模型OOM，400 Bad Request可能是system prompt里混入了不可见Unicode字符，timeout可能是KV cache爆内存而非网络延迟。这些都需要在调用层做分类捕获，而不是统一retry。

2.2 第二层：Prompt工程驱动——当“写得好”成为核心竞争力

裸调行不通，自然转向Prompt Engineering。典型做法是设计一套“思维链”模板：

你是一个专业销售助理，请严格按以下步骤执行： 1. 识别用户需求中的关键实体：时间范围、数据维度、输出格式、接收人 2. 调用sales_data_api获取原始数据（参数：start_date=..., end_date=...） 3. 用pandas清洗并按region分组求和 4. 用python-pptx生成PPT，标题为"XX周销售汇总" 5. 发送邮件至xxx@company.com，主题"【自动】销售周报" 请用JSON格式输出执行计划，字段包括：step, tool_name, params, expected_output

这个方案在POC阶段效果惊艳——准确率从62%提升到89%。但很快遇到瓶颈：当用户说“把华东区数据单独标红”时，模型总在JSON里漏掉highlight_color字段；当销售API返回空数据，模型会虚构数字填进PPT。根本原因在于：Prompt无法强制结构化输出的完备性，也无法校验外部工具返回的真实性。我们做了个统计，在1000次真实调用中，有23%的JSON解析失败（字段缺失/类型错误），17%的工具调用结果未被验证就直接进入下一步。这时候，光靠改prompt已经不够，必须引入输出Schema约束和工具响应校验中间件。

2.3 第三层：框架封装层——LangChain/LlamaIndex的甜蜜陷阱

当团队开始用LangChain，意味着正式进入“框架时代”。典型代码如下：

from langchain.agents import initialize_agent, Tool from langchain.llms import OpenAI tools = [ Tool(name="SalesData", func=get_sales_data, description="查询销售数据"), Tool(name="PPTGenerator", func=gen_ppt, description="生成PPT文件") ] agent = initialize_agent(tools, OpenAI(temperature=0), agent="zero-shot-react-description")

框架确实省去了手动编排的麻烦，但隐藏了更深层的问题。我们部署后发现：

• 状态不可见：Agent执行到哪一步？中间变量存哪了？出错了怎么回溯？LangChain默认用ConversationBufferMemory，所有历史存在内存里，服务重启就全丢；
• 工具无隔离：get_sales_data函数如果内部调用了os.system("rm -rf /")（当然这是极端例子），框架完全无法拦截；
• 超时难控制：设置max_iterations=5，但每次迭代里工具调用可能耗时10秒，总耗时不可控。

我们曾为解决状态问题，把memory后端换成Redis，结果发现LangChain的序列化逻辑会把pandas DataFrame转成超长字符串，单次存储超2MB，Redis频繁OOM。最后不得不自己重写RedisChatMessageHistory，增加DataFrame的pickle压缩和分片存储。这说明：框架封装的便利性，是以牺牲底层可控性为代价的。当你需要定制化时，框架反而成了障碍。

2.4 第四层：Harness Runtime——把Agent当作操作系统来设计

真正破局点，来自一次故障复盘。某天凌晨，销售周报Agent批量失败，日志显示全是tool not found。排查发现：运维同学更新了SalesData服务的API网关，把/v1/sales改成/api/v2/sales，但Agent配置里还是旧地址。更糟的是，所有失败请求都进入了无限重试，占满线程池。这时我们意识到：Agent需要的不是更聪明的LLM，而是一个具备服务治理能力的运行时环境——就像Kubernetes之于容器，Runtime之于Agent。我们参考了微软Semantic Kernel和Google的Vertex AI Agent Builder的设计哲学，但拒绝直接套用，而是基于Go语言从零实现了一个轻量级Harness Runtime，核心包含四个模块：

• Orchestrator（编排器）：接收用户Query，解析成DAG任务图，支持条件分支、并行执行、超时熔断；
• Tool Registry（工具注册中心）：所有工具必须声明输入/输出Schema、SLA承诺（如P95<2s）、健康检查端点，Runtime定期探活；
• State Manager（状态管理器）：用RocksDB做本地状态存储，每个Session ID对应一个LSM树，支持增量快照和WAL日志；
• Observability Hub（可观测中心）：每步执行自动打点，包括LLM输入token数、工具调用耗时、输出结构校验结果，数据直推Prometheus。

这个Runtime不碰LLM推理，只管“怎么跑”，把模型选择、量化、部署完全解耦。上线后，平均故障恢复时间从47分钟降到23秒，因为所有异常都会触发自动降级（如工具不可用时，跳过PPT生成，只发纯文本邮件）。

3. Harness Runtime核心模块实现：不造轮子，但得知道轮子怎么转

3.1 Orchestrator：用DAG替代线性思维链

传统Agent把任务当成一条直线：“思考→调工具→思考→调工具”。但真实业务是网状的。比如“分析竞品动态”可能需要：

• 并行抓取3家竞品官网新闻（I/O密集）
• 同步调用NLP模型提取情感倾向（CPU密集）
• 当任一竞品出现负面新闻时，立即触发告警流程

Harness Runtime用DAG描述这种关系。我们没自己写DAG引擎，而是基于Apache Airflow的DAG DSL做轻量适配。关键改造点有三个：

1. 节点类型扩展：除标准Operator外，新增LLMNode（封装模型调用）、ToolNode（封装工具调用）、DecisionNode（基于LLM输出做路由判断）；
2. 动态边生成：DecisionNode的输出JSON里带next_steps: ["alert_vip", "send_summary"]，Runtime实时解析并创建新边，无需预定义；
3. 资源感知调度：给每个节点标注resource_type: "cpu"或"io"，调度器按机器负载分配，避免CPU密集型任务挤占I/O线程。

实操中，我们用TOML定义DAG：

[dag] name = "competitor_monitor" description = "监控竞品动态并分级响应" [[tasks]] name = "fetch_news" type = "http_get" url = "https://competitor-a.com/news" timeout = 5 [[tasks]] name = "analyze_sentiment" type = "llm_node" model = "llama3-70b" prompt_template = "分析以下新闻的情感倾向：{{ .input }}" [[tasks]] name = "alert_vip" type = "email_send" to = "vip@company.com" condition = "{{ .analyze_sentiment.sentiment == 'negative' }}"

注意：condition字段是Jinja2模板，Runtime在运行时注入上游节点输出。这比硬编码if-else灵活得多，且所有条件表达式都在沙箱里执行，杜绝RCE风险。

3.2 Tool Registry：让工具像微服务一样被治理

工具注册不是简单存个函数指针。Harness Runtime要求每个工具提供YAML描述文件：

name: sales_data_api version: "1.2.0" endpoint: "https://api.company.com/v2/sales" method: "POST" schema: input: type: object properties: start_date: {type: string, format: date} end_date: {type: string, format: date} region: {type: string, enum: ["north", "south", "east", "west"]} output: type: array items: type: object properties: region: {type: string} revenue: {type: number} growth_rate: {type: number} sla: p95_latency_ms: 1200 availability: 0.9995 health_check: endpoint: "/health" timeout_ms: 200

Runtime启动时加载所有YAML，构建工具目录。关键能力在于：

• Schema驱动调用：调用前自动校验输入参数是否符合properties定义，不符合则返回400并记录违规详情，不转发给下游；
• SLA熔断：持续3次P95超时，自动将该工具标记为DEGRADED，后续请求走降级逻辑（如返回缓存数据）；
• 健康巡检：每30秒调用health_check.endpoint，失败5次触发告警，并从可用工具池移除。

我们曾用此机制捕获一个严重问题：某工具在高并发下返回503 Service Unavailable，但HTTP状态码是200，只是body里带{"error":"overload"}。通过在health_check里增加body内容校验规则，Runtime提前2小时发现异常，避免了业务中断。

3.3 State Manager：用RocksDB解决Agent的“健忘症”

Agent需要记住什么？不是整段对话，而是可验证的执行上下文。比如：

• 用户IDu_789在2024-05-20 14:22:03发起“生成周报”请求；
• 步骤1调用sales_data_api，返回[{"region":"east","revenue":120000}]；
• 步骤2调用ppt_gen，生成文件IDf_abc123；
• 当前状态：EXECUTING_STEP_2。

Harness Runtime用RocksDB存储这类结构化状态，每个Session ID作为key，value是Protocol Buffer序列化的SessionState消息。优势非常明显：

• 低延迟：RocksDB本地读写，P99<5ms，远低于Redis网络开销；
• 强一致性：WAL日志确保崩溃后状态可恢复；
• 空间效率：对重复字段（如user_id,request_time）做delta编码，10万Session仅占1.2GB磁盘。

我们对比过其他方案：

• Redis：网络延迟+序列化开销，P95达42ms；
• PostgreSQL：ACID太重，单Session写入需3次磁盘IO；
• 内存Map：服务重启即丢失，不符合生产要求。

最终选择RocksDB，不是因为它多先进，而是它在延迟、可靠性、运维复杂度上取得了最佳平衡。

3.4 Observability Hub：让每一次LLM调用都可审计

Agent的黑盒感，主要来自缺乏可观测性。Harness Runtime的观测点覆盖全链路：

• LLM层：记录input_tokens,output_tokens,stop_reason（stop,length,content_filter），特别关注content_filter——这是模型主动拒绝输出的信号，往往预示prompt越界；
• Tool层：记录tool_name,input_hash（SHA256），response_time_ms,status_code，output_schema_valid（是否符合YAML定义）；
• Orchestrator层：记录dag_id,task_id,state（PENDING/RUNNING/SUCCESS/FAILED），retry_count。

所有数据以OpenTelemetry格式上报，Grafana看板实时展示：

• “LLM拒绝率”看板：追踪stop_reason=content_filter占比，超5%自动告警；
• “工具健康度”看板：按tool_name聚合status_code分布，快速定位劣质工具；
• “DAG成功率”看板：统计各DAG的SUCCESS/FAILED比例，失败时钻取到具体task。

最实用的功能是Trace回放：点击任意失败请求的trace ID，页面自动展开完整执行链，高亮失败节点，并显示该节点的LLM输入原文、工具调用参数、原始响应体。开发人员5秒内就能定位是prompt写错，还是工具API变更。

4. 实战：从零搭建一个可运行的Harness Runtime最小可行版

4.1 环境准备与依赖选择

我们选择Go语言实现Runtime，核心考量三点：

• 并发模型：goroutine + channel天然适合DAG任务调度，一个task一个goroutine，channel传递结果，无锁安全；
• 部署便捷：单二进制文件，无运行时依赖，Docker镜像仅12MB；
• 生态成熟：go.opentelemetry.io/otel、github.com/cockroachdb/pebble（RocksDB替代品，纯Go实现，免CGO）等库质量过硬。

依赖清单（go.mod）：

module harness-runtime go 1.21 require ( github.com/cockroachdb/pebble v1.1.1 // 替代RocksDB，免CGO编译 go.opentelemetry.io/otel v1.21.0 // OpenTelemetry SDK go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp v1.18.0 gopkg.in/yaml.v3 v3.0.1 // 解析工具YAML描述 )

注意：不用RocksDB而选Pebble，是因为我们部署在ARM64服务器上，RocksDB的CGO编译链太复杂。Pebble性能损失<8%，但省去交叉编译噩梦，对中小团队更友好。

4.2 核心数据结构定义

所有模块围绕SessionState展开，用Protocol Buffer定义（session.proto）：

syntax = "proto3"; message SessionState { string session_id = 1; // 唯一标识，如 "sess_abc123" string user_id = 2; // 用户ID string dag_id = 3; // DAG ID，如 "sales_weekly_report" int64 created_at = 4; // Unix毫秒时间戳 repeated TaskState tasks = 5; // 已执行/正在执行的任务状态 map<string, bytes> context = 6; // 键值对形式的上下文，如 "sales_data_json" -> raw bytes } message TaskState { string task_id = 1; // 任务ID，如 "fetch_sales_data" string status = 2; // "PENDING", "RUNNING", "SUCCESS", "FAILED" int64 started_at = 3; int64 finished_at = 4; string error_message = 5; // 失败时的错误详情 int32 retry_count = 6; // 已重试次数 }

用protoc生成Go代码后，SessionState对象即可序列化存入Pebble。关键设计是context字段用map<string, bytes>，而非固定结构体——这样能存任意类型数据（JSON、Protobuf、甚至加密后的二进制），为未来扩展留足空间。

4.3 Orchestrator核心调度逻辑

调度器主循环代码精简如下（orchestrator.go）：

func (o *Orchestrator) Run(ctx context.Context, session *SessionState) error { // 1. 加载DAG定义 dag, err := o.dagLoader.Load(session.DagId) if err != nil { return fmt.Errorf("load dag %s: %w", session.DagId, err) } // 2. 初始化任务队列：所有initial节点入队 queue := make(chan *Task, 100) for _, t := range dag.InitialTasks { queue <- &Task{Id: t.Id, DagId: dag.Id} } // 3. 启动worker池 var wg sync.WaitGroup for i := 0; i < o.workerCount; i++ { wg.Add(1) go func() { defer wg.Done() o.workerLoop(ctx, queue) }() } // 4. 等待所有任务完成或超时 done := make(chan struct{}) go func() { wg.Wait() close(done) }() select { case <-done: return nil case <-time.After(10 * time.Minute): // 全局超时 return errors.New("dag execution timeout") } } func (o *Orchestrator) workerLoop(ctx context.Context, queue chan *Task) { for { select { case task := <-queue: o.executeTask(ctx, task) case <-ctx.Done(): return } } }

executeTask方法根据task.Type分发：

• LLMNode：调用OpenAI API，自动添加response_format={"type":"json_object"}确保结构化输出；
• ToolNode：查Tool Registry，校验输入Schema，调用HTTP endpoint；
• DecisionNode：用LLM输出JSON的next_steps字段，动态向queue发送新任务。

整个调度过程无全局锁，靠channel和goroutine天然并发安全。

4.4 Tool Registry的健康检查实现

健康检查不是简单ping，而是模拟真实调用。HealthChecker结构体如下：

type HealthChecker struct { httpClient *http.Client timeout time.Duration } func (h *HealthChecker) Check(tool *Tool) error { // 构建健康检查请求 req, err := http.NewRequest("GET", tool.HealthCheck.Endpoint, nil) if err != nil { return err } req.Header.Set("User-Agent", "harness-runtime/1.0") // 设置超时 ctx, cancel := context.WithTimeout(context.Background(), h.timeout) defer cancel() req = req.WithContext(ctx) resp, err := h.httpClient.Do(req) if err != nil { return fmt.Errorf("http do: %w", err) } defer resp.Body.Close() // 检查HTTP状态码 if resp.StatusCode != http.StatusOK { return fmt.Errorf("http status %d", resp.StatusCode) } // 可选：校验响应body if tool.HealthCheck.BodyRegex != "" { body, _ := io.ReadAll(resp.Body) if !regexp.MustCompile(tool.HealthCheck.BodyRegex).Match(body) { return errors.New("body regex mismatch") } } return nil }

BodyRegex字段允许定义更严格的健康标准。例如某工具要求/health返回{"status":"ok","version":"1.2.0"}，则正则设为^{"status":"ok","version":"1\.2\.0"}$。这比单纯看200状态码更能反映真实可用性。

5. 避坑指南：那些文档里不会写的实战血泪教训

5.1 LLM输出结构化的“三道防线”，少一道就崩

我们曾以为加个response_format={"type":"json_object"}就能稳住JSON输出，结果线上事故频发。后来总结出必须设三道防线：

实操心得：永远信任第三道防线，但要让前两道尽量减少触发第三道的次数。我们通过日志分析发现，当第一道防线失效率>15%时，大概率是prompt里存在歧义词（如“请输出JSON” vs “请以JSON格式输出”），需重写prompt。

5.2 工具调用的“幂等性”不是可选项，是生死线

某次上线新功能，Agent调用支付接口扣款。测试时一切正常，但生产环境出现重复扣款。根因是：Agent在调用支付API后，收到timeout，但其实支付已成功，只是响应没回来。Agent按策略重试，导致二次扣款。

解决方案是：所有工具必须实现幂等性，且Agent Runtime必须透传幂等键。我们要求：

• 工具API必须支持Idempotency-KeyHTTP Header；
• Runtime在调用工具前，生成idempotency_key := sha256(session_id + task_id + timestamp)；
• 将该key作为Header传入，工具端用Redis记录key → response，相同key直接返回缓存响应。

注意：timestamp必须精确到毫秒，否则同一session内快速重试会生成相同key，导致本该重试的请求被缓存拦截。我们用time.Now().UnixNano()生成。

5.3 状态存储的“冷热分离”，救了我们两次

最初所有Session状态都存Pebble，结果某天磁盘IO飙升，服务变慢。iostat显示await达200ms。排查发现：95%的读请求来自“查询历史Session”，而这些Session早已完成，属于冷数据。

我们立刻实施冷热分离：

• 热数据：最近24小时的Session，存Pebble，保证低延迟；
• 冷数据：24小时前的Session，自动归档到S3，用session_id作为object key；
• 查询逻辑：先查Pebble，未命中则查S3，S3查询结果异步写回Pebble缓存。

改造后，Pebble磁盘IO下降83%，P99延迟从120ms降至8ms。关键是归档逻辑要原子化：先写S3，成功后再删Pebble，避免数据丢失。

5.4 观测数据的“采样率”，别盲目设100%

刚上线Observability Hub时，我们把所有trace设为100%采样，结果Prometheus内存暴涨，Grafana卡顿。后来发现：

• 对于SUCCESS状态的LLM调用，采样率5%足够发现问题（如token异常增长）；
• 对于FAILED或content_filter状态，必须100%采样，这是根因分析的黄金数据；
• 对于tool调用，按tool_name分层采样：核心工具（如支付、数据库）100%，边缘工具（如天气查询）1%。

现在我们的采样策略是动态的：

func (o *ObservabilityHub) ShouldSample(span *trace.SpanData) bool { if span.Status.Code == codes.Error { return true // 失败必采 } if span.Name == "llm_call" && span.Attributes["stop_reason"] == "content_filter" { return true // 内容过滤必采 } return rand.Intn(100) < o.baseSamplingRate // 基础采样率，默认5% }

这套策略让观测数据量下降92%，但问题发现率反升15%，因为工程师看到的都是高价值trace。

6. 性能压测与生产调优：真实数据说话

6.1 基准测试环境与方法

我们在阿里云ECS上搭建压测环境：

• Server：ecs.g7ne.2xlarge（8核32G，增强型网络）
• Client：4台ecs.c7.2xlarge（8核16G），用k6分布式压测
• 测试场景：DAG含3个节点（LLM Node + Tool Node + Decision Node），LLM用Qwen2-7B本地部署（vLLM），Tool是mock HTTP服务（固定200ms延迟）

压测指标：

• 吞吐量（TPS）：每秒成功完成的Session数；
• P95延迟：从接收请求到返回最终结果的耗时；
• 错误率：HTTP 5xx + Runtime内部错误占比。

6.2 关键参数调优实录

我们测试了不同goroutine worker数对性能的影响：

结论：Worker数不是越多越好，要匹配CPU核心数×2~3倍。我们服务器8核，64 worker（8×8）达到最佳，再往上就是负优化。

另一个关键参数是Pebble的Options：

opts := &pebble.Options{ MemTableSize: 64 << 20, // 64MB LevelMultiplier: 10, NumPrevManifest: 0, DisableWAL: false, BytesPerSync: 512 << 10, // 512KB }

调优重点：

• MemTableSize设为64MB（默认4MB）：减少memtable flush频率，降低IO毛刺；
• BytesPerSync设为512KB（默认0）：强制WAL日志每512KB刷盘，平衡持久性与性能；
• DisableWAL必须false：否则崩溃可能丢失未flush的数据。

调优后，Pebble的P99写入延迟从210ms降至12ms，整体DAG P95下降19%。

6.3 生产环境监控告警配置

我们用Prometheus+Alertmanager配置了四级告警：

特别注意P0告警的job="harness"标签，确保只监控Runtime自身，不被其他服务指标干扰。所有告警都配置runbook_url，链接到内部Wiki的故障处理手册，SRE拿到告警就能直接执行SOP。

7. 未来演进：当Harness Runtime遇上边缘计算与多模态

7.1 边缘侧Runtime：让Agent在手机端“活”起来

当前Runtime部署在中心云，但很多场景需要离线能力。比如销售代表在无网络的工厂巡检时，需用手机Agent识别设备铭牌并查维修记录。我们正在实验边缘Runtime：

• 模型：用llama.cpp量化Qwen2-1.5B，4-bit量化后仅700MB，iPhone 14可运行；
• 工具：手机相册、相机、本地SQLite数据库作为“工具”，Runtime通过iOS Extension调用；
• 状态：Session状态存Core Data，同步到iCloud，网络恢复后自动补全云端记录。

挑战在于LLM推理速度。实测iPhone 14 Pro上，Qwen2-1.5B 4-bit的token生成速度仅3.2 token/s。解决方案是：用Speculative Decoding——主模型（Qwen2-1.5B）生成，小模型（Phi-3-mini）并行预测下一个token，主模型验证，提速至8.7 token/s。这需要Runtime层深度集成推理引擎，不再是简单调用API。

7.2 多模态Runtime：不只是文本，还有图像与语音

下一代Agent必须处理多模态输入。我们已将Harness Runtime扩展为MultiModal Runtime：

• 输入适配器：图像输入经CLIP-ViT-L/14编码为embedding，语音输入经Whisper-large-v3转文本+情感标签；
• DAG扩展：新增ImageNode（调用多模态模型如Qwen-VL）、AudioNode（调用语音合成）；
• 状态统一：所有模态数据存入Pebble时，用content_type标签区分（text/plain,image/jpeg,audio/wav）。

实测案例：用户拍一张电路板照片，说“这个元件坏了，能换吗？”。Runtime执行：

1. ImageNode调Qwen-VL识别元件型号（C1234）；
2. ToolNode查ERP系统，返回C1234库存为0；
3. AudioNode调TTS生成语音：“该元件暂无库存，建议联系采购”。

关键突破是跨模态状态传递：图像识别结果（JSON）和语音合成参数（struct）能无缝在DAG中流转，靠的是统一的context字段和动态Schema解析。

7.3 我个人的体会：Runtime的价值不在“多酷”，而在“多稳”

写这篇的时候，我翻出了三年前的笔记，那时我们还在为“Agent调用一次LLM失败就整个流程卡死”焦头烂额。现在，同样的场景，Harness Runtime会：

• 自动重试（最多3次）；
• 重试失败则降级（用缓存数据生成简化版PPT）；
• 同时发告警给运维