企业官网建设流程全解析

1. 为什么“能跑通Demo”和“能上生产”之间隔着一道鸿沟

如果你最近半年在折腾大模型应用，大概率经历过这样一个阶段：用几十行代码把几个工具串起来，让模型自己决定调哪个函数、传什么参数，跑通一个“查天气+订机票”的Demo，然后兴奋地觉得Agent不过如此。但当你真正想把它塞进一个每天要处理上万次请求的业务系统里时，问题就全冒出来了——模型偶尔抽风调用不存在的工具、多轮对话里上下文越滚越长导致成本失控、某个工具超时之后整个链路卡死、并发一上来状态就串了。

这些问题的根源，不在于模型不够聪明，而在于你缺了一层东西：Agent Runtime。很多人把Agent理解成“提示词+工具调用”，这没错，但那只是逻辑层面的描述。真正让Agent在生产环境里稳定运转的，是一套运行时系统，它负责调度、状态管理、错误恢复、资源控制、可观测性等等。你可以把Agent的逻辑想象成一份菜谱，而Runtime就是那个厨房——灶台、排烟、备菜台、出餐口，缺一样都做不出一桌稳定的菜。

这篇内容我想聊的是Agent编排技术的全景，从底层的执行模型讲起，一直讲到工程落地时那些文档里不会写的坑。关键词会围绕Agent Runtime、编排引擎、工具调用、状态机、执行图、可观测性、错误恢复这些展开。适合两类人看：一类是已经写过Agent Demo、想往生产级推进的开发者；另一类是在做平台型产品、需要给业务方提供Agent能力的架构同学。我不会只讲概念，每个环节都会落到“为什么这么设计”和“实际怎么落地”上。

先说一个反直觉的结论：Agent Runtime的核心难点从来不是“让模型调用工具”，而是“在模型不可靠的前提下，保证系统可靠”。模型本身是概率性的，它可能返回格式错误的参数、可能陷入循环、可能对同一个问题给出不同答案。Runtime的职责，就是在这个不确定的地基上，盖一栋能住人的楼。接下来我会从执行模型、编排范式、状态与上下文、工具层设计、错误处理、可观测性、性能与成本这几个维度，一层层拆开讲。

2. Agent Runtime的执行模型：从“一次调用”到“一个生命周期”

2.1 单次推理循环到底发生了什么

要理解Runtime，得先看清楚一次Agent执行的最小单元。很多人以为Agent就是“用户输入→模型→工具→模型→输出”这么一条线，但实际上每一次模型调用都是一个完整的生命周期，里面包含了好几个阶段。

第一步是输入组装。Runtime需要把系统提示词、历史对话、可用工具的描述、当前用户输入，按照模型能理解的格式拼成一个完整的请求。这一步看似简单，但坑很多：工具描述太长会挤占上下文窗口，历史对话不做裁剪会无限增长，不同模型对消息角色的支持还不一样。我见过一个项目，工具描述写了三千多字，结果模型还没开始干活，上下文就用掉了一半。

第二步是推理与解析。模型返回的内容可能是纯文本，也可能是结构化的工具调用请求。Runtime需要解析这个返回，判断模型是想直接回复用户，还是想调用某个工具。这里的关键是格式约束——你得让模型按照你期望的格式输出，否则解析就会失败。常见的做法是用JSON Schema约束输出结构，或者在提示词里明确要求“如果需要调用工具，请输出特定格式”。

第三步是工具执行。解析出工具名和参数之后，Runtime要去实际执行这个工具。这一步是同步还是异步、超时怎么设、失败了重试几次、重试的时候参数要不要变，都是Runtime要决策的。

第四步是结果回填与再推理。工具执行的结果要作为新的消息塞回上下文，再次调用模型。这个循环会一直持续，直到模型决定不再调用工具、直接给出最终答案，或者触发了某个终止条件（比如达到最大轮次）。

把这四步串起来，就是一个推理循环。一个Agent的一次完整任务执行，可能包含一到几十个这样的循环。Runtime要做的，就是管理好每一个循环的输入输出、状态流转和资源消耗。

2.2 为什么需要显式的状态机而不是隐式的while循环

我早期写Agent的时候，最自然的写法就是一个while循环：只要模型还想调工具，就继续循环。这种写法在Demo阶段没问题，但上了生产就会暴露几个致命问题。

第一个问题是状态不可见。while循环里的状态都藏在局部变量里，外部系统根本不知道当前Agent执行到哪一步了。用户刷新了页面怎么办？服务重启了怎么办？你没法恢复。

第二个问题是无法中断和干预。如果某个Agent执行到一半，运营人员发现它走偏了想手动终止，或者需要人工审核某个工具调用，隐式循环根本插不进去。

第三个问题是难以做超时和配额控制。你没法精确知道当前是第几轮、已经消耗了多少token、还能不能再调一次工具。

所以生产级的Runtime，几乎都会把执行过程建模成一个显式的状态机。每个状态是一个明确的节点，比如“等待模型响应”“解析工具调用”“执行工具”“生成最终答案”“异常终止”。状态之间的转移有明确的条件，整个执行过程可以被持久化、被查询、被恢复、被干预。

这里有个设计上的取舍：状态机越细，控制力越强，但实现复杂度也越高。我的经验是，至少要把“模型推理”“工具执行”“结果处理”这三个阶段拆成独立状态，因为它们各自的失败模式和重试策略完全不同。模型推理失败可能是网络问题，工具执行失败可能是业务逻辑问题，混在一起处理会很别扭。

2.3 执行图：当Agent不再是单线流程

状态机解决的是单个Agent的执行问题，但真实业务里，一个任务往往需要多个Agent协作。比如一个客服场景，可能需要“意图识别Agent”先判断用户想干什么，然后路由到“订单查询Agent”或“退款处理Agent”，退款处理又可能需要“风控审核Agent”介入。

这时候单线状态机就不够了，你需要的是执行图（Execution Graph）。执行图把每个Agent或每个处理步骤看作一个节点，节点之间的连线表示数据流向和控制流转。执行图可以是线性的，也可以是带分支和合并的DAG（有向无环图），甚至可以是带循环的。

执行图带来的好处是编排逻辑和业务逻辑解耦。业务方只需要描述“先做A，根据A的结果决定做B还是C，B和C都完成后做D”，Runtime负责把这个图翻译成实际的执行计划，处理并发、依赖、错误传播。

但执行图也引入了新的复杂度：节点之间怎么传数据？一个节点的输出要映射到下一个节点的输入，这个映射关系谁维护？如果某个节点失败了，是重试整个图还是只重试这个节点？这些问题在单Agent场景下不存在，在多Agent编排里却是天天要面对的。

我个人的经验是，执行图的粒度不要太细。有些团队恨不得把每一次模型调用都做成一个节点，结果图复杂到没人看得懂。合理的做法是，把“一个Agent的一次完整任务”作为一个节点，节点内部的状态流转由Agent自己的状态机管理，节点之间才用执行图编排。这样既保留了编排的灵活性，又不至于让图变得不可维护。

3. 编排范式之争：ReAct、Plan-and-Execute还是工作流

3.1 ReAct的适用边界在哪里

ReAct（Reasoning + Acting）大概是目前最广为人知的Agent编排范式。它的核心思想是让模型在每一步都先“想一下”（Reasoning），再决定“做什么”（Acting），然后观察结果（Observation），继续下一轮。这个范式的好处是灵活，模型可以根据中间结果动态调整策略，不需要预先规划好所有步骤。

但ReAct有个被低估的局限：它假设每一步的决策成本是可控的。在简单任务里，比如“查一下明天天气然后告诉我穿什么”，ReAct跑个三四轮就结束了，成本可以接受。但在复杂任务里，比如“帮我分析这份财报并生成投资建议”，ReAct可能会跑几十轮，每一轮都要把完整的历史上下文塞给模型，token消耗呈平方级增长。

更麻烦的是，ReAct容易陷入局部最优。模型每一步都选当前看起来最合理的动作，但缺乏全局规划，可能走到一半发现方向错了，又得回头重来。我见过一个Agent在“查资料”和“整理资料”之间反复横跳，跑了二十多轮还没输出结果。

所以ReAct适合的是步骤数少、决策路径短、对实时性要求高的场景。一旦任务复杂度上来了，就得考虑其他范式。

3.2 Plan-and-Execute如何解决长任务问题

Plan-and-Execute的思路很直接：先让模型做一个完整的计划，把任务拆成若干步骤，然后按步骤执行。执行过程中如果需要调整，再重新规划。这个范式的好处是全局视野——模型在规划阶段能看到任务全貌，不会走着走着迷路。

但它的代价是规划质量高度依赖模型能力。如果模型规划得不好，后面执行全是白费。而且计划一旦制定，执行过程中环境变化了怎么办？比如计划里要查某个数据库，执行时发现数据库连不上，是重新规划还是跳过？这些都需要Runtime有相应的处理机制。

我的实践体会是，Plan-and-Execute更适合步骤明确、依赖关系清晰的任务，比如数据处理流水线、报告生成这类。对于需要大量探索和试错的任务，纯Plan-and-Execute反而会束缚模型的手脚。一个折中的方案是分层规划：先做一个粗粒度的计划，每个粗步骤内部再用ReAct的方式灵活执行。这样既有全局方向，又保留了局部灵活性。

3.3 工作流编排：把确定性交给代码，把不确定性交给模型

还有一种被很多人忽视的范式是工作流编排。它的核心思想是：能用代码写死的逻辑就用代码写死，只在真正需要模型判断的地方才调用模型。

举个例子，一个“合同审核”Agent，流程可能是：先提取合同文本（代码做OCR）、然后识别关键条款（模型做）、然后比对标准条款库（代码做）、最后生成审核意见（模型做）。这个流程里，哪些步骤用模型、哪些用代码，是明确设计的，不是让模型自己决定的。

工作流编排的好处是可控性极强。每个环节的输入输出都是确定的，测试和调试都容易。缺点是灵活性差，遇到流程外的输入就处理不了。

实际生产中，我见过最稳的Agent系统，往往是工作流为主、ReAct为辅的混合架构。主流程用工作流编排保证稳定性，在需要灵活决策的节点上，嵌入一个ReAct子Agent。这样既不会因为模型的不确定性导致整个流程崩溃，又能在关键环节保留智能。

4. 状态与上下文管理：Agent Runtime最容易被低估的部分

4.1 上下文窗口不是越大越好

很多人觉得上下文窗口越大越好，恨不得把整个对话历史、所有工具描述、全部知识库都塞进去。但实际用下来，上下文越长，模型注意力越容易涣散。有研究表明，当上下文超过一定长度后，模型对中间部分信息的召回率会明显下降，这就是所谓的“迷失在中间”现象。

所以Runtime必须做上下文管理，而不是无脑拼接。常见的策略有几种：一是滑动窗口，只保留最近N轮对话；二是摘要压缩，把早期对话用模型总结成一段简短摘要；三是关键信息提取，只保留与当前任务相关的实体和事实。

这几种策略各有取舍。滑动窗口实现简单，但可能丢掉重要信息；摘要压缩保留了语义，但摘要本身可能失真；关键信息提取最精准，但需要额外的提取逻辑。我的建议是组合使用：近期对话用滑动窗口保留原文，中期对话做摘要，远期对话只保留结构化的事实。这样在成本和效果之间能找到一个不错的平衡点。

4.2 会话状态、任务状态和全局状态要分开管

状态管理最容易犯的错误，是把所有状态混在一起。我见过一个系统，把用户会话、当前任务进度、工具调用缓存全塞在一个大字典里，结果就是改一处崩一片。

合理的做法是分层管理状态。至少分三层：

• 会话状态：跟用户相关的长期信息，比如用户ID、偏好设置、历史交互摘要。这层状态跨任务存在，生命周期最长。
• 任务状态：当前这次Agent执行的相关信息，比如任务ID、当前执行到哪个节点、已经调用了哪些工具、中间结果是什么。任务结束这层状态就可以归档。
• 执行状态：单次推理循环的临时状态，比如当前请求的token数、重试次数。这层状态生命周期最短，循环结束就丢弃。

分层之后，每层状态的存储介质、过期策略、访问权限都可以独立设计。会话状态可能需要持久化到数据库，任务状态可以放Redis，执行状态直接在内存里就行。混在一起的话，你没法给它们分别设计生命周期。

4.3 状态持久化与恢复：服务重启了Agent还能接着跑吗

生产环境里，服务重启、节点扩容、网络抖动都是常态。如果Agent执行到一半服务挂了，重启之后能不能接着跑，这是区分Demo和生产的硬指标。

要做到这一点，Runtime必须支持状态持久化。每执行完一个状态节点，就把当前状态快照存下来。恢复的时候，从最后一个快照继续执行。这里的关键是幂等性——恢复后重新执行某个节点，不能产生副作用。比如“扣款”这个工具，如果执行到一半挂了，恢复后不能重复扣款。解决办法是给每个工具调用分配唯一ID，执行前先检查这个ID是否已经执行过。

还有一个容易被忽略的点是状态版本管理。Agent的逻辑可能会迭代，今天的状态结构跟明天的不一样。如果持久化的状态是旧版本的，恢复时就会解析失败。所以状态结构里要带版本号，Runtime要能处理版本迁移。

5. 工具层的设计：Agent的手和脚怎么接才稳

5.1 工具描述的质量直接决定调用准确率

工具调用准不准，很大程度上取决于工具描述写得好不好。我见过太多团队，工具描述就写一句“查询订单信息”，参数就写个“order_id”。模型看到这种描述，根本不知道什么时候该调、参数该传什么格式。

好的工具描述应该包含几个要素：功能说明（这个工具干什么）、使用场景（什么时候该用）、参数说明（每个参数的含义、类型、是否必填、取值范围）、返回说明（返回什么结构）、示例（一个完整的调用示例）。这些信息看起来啰嗦，但能显著提升模型的调用准确率。

还有一个技巧是给工具起个好名字。名字要能自解释，比如query_order_by_id就比get_info好得多。模型在选择工具时，名字是重要的判断依据。

5.2 参数校验和容错：别让模型的“手滑”搞崩系统

模型生成参数时，格式错误是家常便饭。可能少个引号、可能类型不对、可能传了个不存在的枚举值。Runtime必须在工具执行前做参数校验，校验不通过就返回明确的错误信息给模型，让它重新生成。

校验之外还要有容错。比如模型传了个字符串“123”，但工具期望的是整数，Runtime可以尝试自动转换。模型传了个日期“明天”，工具期望的是“2024-01-01”格式，Runtime可以尝试解析。这些容错逻辑能大幅降低模型的调用失败率。

但容错要有边界。涉及资金、权限、数据修改的操作，宁可失败也不能猜。模型传了个模糊的参数，你猜错了可能就是生产事故。这种情况下，Runtime应该直接拒绝执行，把问题抛回给模型或人工。

5.3 工具执行的隔离与超时控制

工具执行是Agent里最不可控的环节。它可能是个HTTP请求，可能是个数据库查询，可能是个耗时的计算任务。如果不做隔离，一个慢工具就能拖垮整个Agent。

基本的做法是给每个工具调用设超时。超时时间根据工具类型来定，查询类可以短一点（比如5秒），计算类可以长一点（比如30秒）。超时之后，Runtime要决定是重试、跳过还是终止整个任务。

更进一步的做法是资源隔离。把工具执行放在独立的线程池或进程池里，一个工具出问题不会影响其他工具。对于特别危险的工具（比如执行代码），还要做沙箱隔离。

还有一个实践中的坑：工具执行结果可能非常大。比如查询数据库返回了几万行，直接塞回上下文会把窗口撑爆。Runtime需要对工具结果做截断或摘要，只把关键信息回填给模型。

6. 错误处理与可观测性：Agent出问题时你怎么知道

6.1 Agent的失败模式比传统系统复杂得多

传统系统的错误很明确：抛异常、返回错误码、超时。Agent的失败模式要隐蔽得多：模型可能返回了一个格式正确但语义错误的答案，可能陷入了循环但每轮输出都不一样，可能调用了正确的工具但传了错误的参数。这些失败不会抛异常，但结果就是不对。

所以Runtime需要一套专门的失败检测机制。常见的检测点包括：输出格式校验（返回的JSON能不能解析）、语义校验（返回的内容是否符合预期结构）、循环检测（是否在重复调用同一个工具）、进度检测（是否长时间没有实质性进展）。

检测到异常之后，处理策略也要分层。轻微的格式问题可以自动重试，语义问题可能需要换个提示词重试，循环问题需要强制中断并换策略，严重的逻辑错误可能需要人工介入。

6.2 日志、追踪、指标：三件套一个都不能少

可观测性是生产系统的生命线，Agent Runtime尤其如此。因为Agent的执行路径是动态的，出了问题你没法靠读代码来定位，只能靠观测数据。

日志要记录每个关键节点的输入输出，包括模型请求、模型响应、工具调用、工具结果。日志要结构化，方便后续检索和分析。

追踪要能还原一次完整执行的调用链。每个Agent任务分配一个trace ID，每个状态节点分配一个span ID，这样你能清楚地看到时间花在了哪里、哪个环节出了问题。

指标要覆盖几个维度：执行成功率、平均执行轮次、平均token消耗、工具调用成功率、各环节耗时分布。这些指标能帮你发现系统性的问题，比如某个工具的成功率突然下降，或者平均轮次在上升。

我特别想强调成本指标。Agent的token消耗可能非常惊人，如果不做监控，月底账单会教你做人。至少要监控每个任务的token消耗、每个工具的调用频率、缓存命中率这些。

6.3 人工介入：什么时候该让Agent停下来

再好的Runtime也不能保证Agent永远正确。有些场景下，让Agent继续跑下去风险太大，必须停下来让人来判断。比如涉及资金操作、涉及敏感数据、Agent连续多次失败、Agent的输出置信度低。

Runtime需要提供人工介入的接口。可以在执行图的某个节点设置“审批点”，执行到这里就暂停，等人工确认后再继续。也可以设置“熔断机制”，当某个指标超过阈值时自动暂停所有相关任务。

人工介入的体验也很重要。审批人需要看到足够的信息来做判断：Agent想干什么、为什么这么干、已经干了什么、可能的风险是什么。这些信息都要在审批界面上清晰呈现。

7. 性能与成本：让Agent跑得又快又便宜

7.1 并发控制：不是所有任务都能并行

Agent任务天然适合并行，因为很多步骤之间没有依赖。但并行不是无脑开线程，需要做并发控制。

首先是并发度限制。模型API通常有速率限制，工具服务也有承载上限。Runtime需要根据下游能力来限制并发数，而不是有多少任务就开多少。

其次是依赖管理。执行图里有些节点可以并行，有些必须串行。Runtime要能识别依赖关系，把无依赖的节点并行执行，有依赖的按顺序执行。

还有一个容易被忽略的点是资源竞争。多个Agent同时调用同一个工具，可能会互相影响。比如都去查同一个数据库，把连接池占满了。Runtime需要做资源池化管理，避免单个工具被压垮。

7.2 缓存策略：哪些能缓存，哪些不能

缓存是降本增效的利器，但Agent场景下的缓存要特别小心。模型推理结果不能随便缓存，因为同样的输入在不同上下文下可能应该有不同的输出。但有些东西是可以缓存的：

• 工具描述和系统提示词：这些是静态的，可以缓存起来避免重复组装。
• 工具调用结果：对于幂等的查询类工具，相同参数的调用结果可以缓存一段时间。
• 嵌入向量：如果Agent用了RAG，文档的嵌入向量可以缓存。
• 模型响应：对于确定性的、低风险的调用，可以考虑缓存。但要设置合理的过期时间和失效条件。

缓存的key设计很关键。不能只用输入文本做key，还要考虑上下文、模型版本、参数配置这些因素。否则缓存命中率上去了，但返回的是错误的结果。

7.3 模型选型与降级：不是所有步骤都需要最强模型

一个Agent任务里，不同步骤对模型能力的要求是不一样的。意图识别可能用小模型就够了，复杂推理才需要大模型。Runtime应该支持按步骤配置模型，在保证效果的前提下尽量用便宜的模型。

还可以做动态降级。当大模型调用失败或超时时，自动降级到小模型。或者当任务优先级低时，直接用便宜模型处理。这些策略能显著降低成本。

另一个降本手段是减少不必要的模型调用。有些步骤其实可以用规则或小模型替代，没必要每次都调大模型。比如参数校验、格式转换这些，用代码做比用模型做又快又便宜。

8. 从零搭一个Runtime：我的技术选型思路

8.1 自研还是用框架

这是每个团队都会面临的问题。我的看法是：如果你的Agent逻辑很简单，用现成框架就行；如果逻辑复杂、有定制需求，自研更可控。

现成框架的好处是开箱即用，社区活跃，踩坑有人帮你踩过了。但缺点是抽象层次可能跟你的需求不匹配，遇到框架不支持的功能就得绕路走，反而更麻烦。

自研的好处是完全可控，想怎么改就怎么改。但代价是工作量大，很多基础设施要自己搭。我的建议是核心的编排和状态管理自研，周边的可观测性、存储、消息队列用成熟组件。这样既保证了核心逻辑的可控性，又不用重复造轮子。

8.2 核心模块的划分

一个完整的Runtime，我倾向于划分成这几个模块：

• 编排引擎：负责解析执行图、调度节点执行、管理状态流转。
• 模型网关：统一封装不同模型的调用，处理重试、降级、限流。
• 工具注册中心：管理工具的注册、发现、描述、版本。
• 状态存储：负责状态的持久化和恢复。
• 可观测性模块：日志、追踪、指标的采集和上报。
• 控制面：提供人工介入、任务查询、配置管理的接口。

这些模块之间通过明确的接口通信，可以独立演进。比如模型网关要支持新模型，不影响编排引擎；状态存储要换数据库，不影响工具层。

8.3 落地路线图：别想一步到位

搭Runtime最忌讳的就是想一步到位。我见过团队花三个月搭了个“完美”的Runtime，结果业务需求变了，一半功能用不上。

合理的路线是迭代演进。第一版只做最核心的：单Agent执行、基础状态管理、简单工具调用。跑通之后，加上多Agent编排、错误重试、可观测性。再之后，做性能优化、成本控制、人工介入。每一步都基于实际需求来驱动，而不是为了架构而架构。

我自己的经验是，第一个版本两周内要能跑起来。哪怕很粗糙，但能跑通端到端流程，后面的迭代才有基础。如果一开始就追求完美，很可能永远出不了第一版。

9. 那些文档里不会写的踩坑经验

9.1 模型返回的JSON为什么总是解析失败

这个问题我踩过无数次。模型返回的JSON，看起来是对的，但JSON.parse就是报错。原因通常有几个：模型在JSON外面包了markdown代码块标记、JSON里有尾随逗号、字符串里有未转义的特殊字符、模型用了单引号而不是双引号。

解决办法是做健壮的解析。先尝试直接解析，失败就尝试提取代码块内容，再失败就尝试修复常见格式问题（比如替换单引号、去掉尾随逗号），最后还失败就把原始返回和错误信息一起抛给模型让它重新生成。这个解析逻辑要封装成工具函数，所有地方统一用。

9.2 工具调用陷入死循环怎么破

模型有时候会反复调用同一个工具，每次参数略有不同，但就是出不来。这种情况通常是因为工具返回的结果没有给模型足够的信息来推进任务。

解决办法有几个：一是设置最大轮次，超过就强制终止；二是检测重复调用，如果连续几轮调用同一个工具且参数相似，就中断并提示模型；三是优化工具返回，让返回结果包含更明确的下一步指引。我通常三个一起用，效果比较稳。

9.3 上下文爆炸的预防比治疗重要

上下文爆炸是Agent成本失控的头号原因。预防的手段包括：工具结果做截断、历史对话做摘要、不必要的信息不塞进上下文、用结构化数据代替自然语言描述。

还有一个技巧是分离“思考上下文”和“执行上下文”。模型推理时需要的上下文，和工具执行时需要的上下文，可以不一样。工具执行只需要参数，不需要完整的历史对话。把这两者分开管理，能省下大量token。

9.4 并发下的状态串扰

这个问题在多用户场景下特别隐蔽。两个用户的Agent任务同时执行，如果状态存储的key设计不当，可能会互相覆盖。比如都用current_task做key，那肯定串。

解决办法是状态key必须包含足够的隔离维度：用户ID、会话ID、任务ID，一层都不能少。而且状态读写要加锁或使用乐观锁，避免并发写冲突。这个坑我在早期项目里踩过，排查了一整天才定位到。

10. 我对Agent Runtime未来演进的一点判断

聊了这么多工程细节，最后说点偏趋势的观察。Agent Runtime这个领域，目前还处在“每家都在自己造轮子”的阶段，但已经开始出现一些共识：执行图会成为编排的标准抽象、状态管理会走向标准化、可观测性会成为标配而非选配。

我个人的判断是，未来Runtime的竞争力不在于支持多少种编排范式，而在于对不确定性的管理能力。谁能更好地处理模型的幻觉、工具的失败、上下文的膨胀、成本的失控，谁就能让Agent真正在生产环境里跑起来。技术选型上，我倾向于保持轻量和可组合，不要追求大而全的框架，而是把每个环节做扎实，让团队能按需拼装。

如果你正在搭自己的Runtime，我的建议是：先把单Agent的执行闭环跑稳，再考虑多Agent编排；先把可观测性做起来，再谈性能优化；先接受模型会犯错这个事实，再设计容错机制。这条路没有捷径，但每一步踩实了，后面会越来越顺。