1. 为什么"能跑起来"和"跑得稳"之间隔着一整个运行时
智能体开发这件事，2026年已经不算新鲜了。从Coze、扣子这类平台拖拽式搭建，到用Python手写ReAct循环，再到基于Rust做底层Agent调度，大家手里或多或少都跑通过几个Demo。但如果你真正把智能体丢进生产环境——比如接入客服系统、跑代码审查流水线、做多轮销售跟进——你会发现一个很尴尬的事实：Demo阶段跑通的那套逻辑，到了真实交互场景里几乎必然崩。
崩的方式还特别多样。用户一句话里塞了三个意图，你的Agent只识别了第一个；工具调用返回了非预期格式，整个循环直接卡死；两个子Agent同时想写同一份记忆，后写的把先写的覆盖了；对话轮次一多，上下文窗口爆了，Agent开始胡言乱语。这些问题的共同点是：它们都不是"模型不够聪明"导致的，而是"运行时不够健壮"导致的。
这就是"Flowing"这个项目要解决的核心问题。它是一个面向复杂交互的轻量级智能体运行时框架。注意这里的三个关键词：复杂交互、轻量级、运行时。复杂交互意味着它不是为单轮问答设计的，而是要处理多意图、多轮次、多工具、多Agent协作的场景；轻量级意味着它不打算做成一个大而全的平台，而是提供一个可以嵌入现有系统的核心引擎；运行时意味着它关注的不是"怎么定义Agent"，而是"Agent跑起来之后怎么调度、怎么容错、怎么管理状态"。
我之所以对这个方向特别有感触，是因为过去一年里我至少见过五六个团队在"平台搭建的智能体"和"用Python手写的智能体"之间反复横跳。平台搭的智能体上手快，但一旦遇到平台不支持的交互模式就束手无策；手写的灵活，但每加一个功能就要自己处理并发、重试、状态同步，代码很快就变成一团乱麻。Flowing这类运行时框架的价值，恰恰在于它把"调度、容错、状态管理"这些脏活累活从业务逻辑里剥离出来，让你专注于定义Agent的行为本身。
这篇文章我会从运行时的核心设计出发，拆解Flowing在复杂交互场景下的关键机制，包括它的调度模型、容错策略、记忆管理和并发处理思路。适合已经写过至少一个Agent Demo、正准备把它推向更复杂场景的开发者阅读。如果你还在纠结"Agent是什么"或者"该用Coze还是手写"，这篇文章可能对你偏深，但读下去也能帮你建立对运行时层的正确认知。
2. 复杂交互到底复杂在哪：从单轮问答到多Agent协作的鸿沟
2.1 交互复杂度的四个层级
要理解Flowing的设计动机，得先搞清楚"复杂交互"这个词到底指什么。我把它拆成四个层级，每一层对运行时的要求都不一样。
第一层是单轮单意图。用户问"今天天气怎么样"，Agent调用天气工具，返回结果。这是最简单的场景，几乎任何框架都能处理，甚至一个while循环加几个if-else就够了。
第二层是单轮多意图。用户说"帮我查一下明天北京的天气，顺便看看有没有适合穿外套的温度，再推荐一个室内活动"。这一句话里有三个意图，而且第三个意图依赖第二个意图的输出。运行时需要做意图拆分、依赖分析、执行顺序编排。很多手写Agent在这里就开始出问题了，因为它们通常假设一次输入对应一次工具调用。
第三层是多轮有状态。用户在第一轮说"我想订一张去上海的票"，第二轮说"改成后天"，第三轮说"算了还是去杭州吧"。每一轮都依赖前几轮积累的状态，而且状态之间可能存在冲突（去上海vs去杭州）。运行时需要维护一个可追溯、可回滚的状态机，而不是简单地把历史对话拼进prompt。
第四层是多Agent协作。一个主Agent负责理解用户意图，拆解出子任务后分发给专门的子Agent——比如一个负责查数据、一个负责生成文案、一个负责审核合规性。子Agent之间可能需要共享部分记忆，也可能需要互相等待对方的输出。这时候运行时本质上变成了一个分布式调度系统，要处理并发、死锁、资源竞争等问题。
Flowing的定位是覆盖第二层到第四层。它不试图解决第一层的问题，因为那太简单了，用不着框架。它的"轻量级"体现在：不引入消息队列、不依赖外部数据库、不强制特定的Agent定义方式，核心运行时可以作为一个库嵌入到现有服务里。
2.2 为什么现有方案在第三、四层容易翻车
我观察到一个很普遍的现象：很多团队用平台搭建的智能体，在第二层还能勉强应付，到了第三层就开始出现"记忆混乱"，到了第四层直接放弃，退化成一个大Agent包揽所有事情。这不是平台的问题，而是平台的设计假设和复杂交互的需求不匹配。
平台类产品通常假设Agent是"无状态"的，每次对话独立处理，状态通过对话历史隐式传递。这在简单场景下没问题，但到了多轮有状态场景，对话历史会迅速膨胀，而且模型很难从一长串历史里准确提取出"当前有效状态"。更麻烦的是，当多个子Agent需要共享状态时，平台通常没有提供显式的状态管理机制，你只能通过把状态塞进prompt来传递，这既低效又容易出错。
手写Agent的问题则相反：灵活但缺乏约束。你可以用任何方式管理状态，但正因为没有约束，很容易写出"状态散落在十几个变量里、没有任何一致性保证"的代码。一旦并发上来，或者某个工具调用超时，状态就可能处于一个不一致的中间态，后续逻辑基于这个中间态继续跑，错误就会累积放大。
Flowing的思路是：提供一个显式的、有约束的状态管理模型，同时保持足够的灵活性。它不强制你用某种特定的Agent定义方式，但它强制你通过它提供的接口来读写状态、注册工具、声明依赖。这样运行时就能在底层做一致性保证、并发控制和容错处理。
2.3 运行时框架和Agent框架的区别
这里需要澄清一个容易混淆的概念。市面上很多叫"Agent框架"的东西，比如LangChain、AutoGen，它们主要解决的是"怎么定义Agent"和"怎么编排Agent之间的调用"。而"运行时框架"关注的是"Agent定义好之后，怎么让它稳定地跑起来"。
打个比方：Agent框架像是编程语言的语法和标准库，运行时框架像是虚拟机和垃圾回收器。你可以用语法写出程序，但程序能不能稳定运行、内存会不会泄漏、并发会不会出问题，取决于运行时。
Flowing把自己定位在运行时层，意味着它不关心你用什么样的prompt模板、用哪个模型、定义了多少个工具。它关心的是：当这些Agent开始执行时，怎么调度它们的执行顺序、怎么在某个步骤失败时重试或降级、怎么保证多个Agent并发读写状态时不冲突、怎么在上下文超限时做压缩或截断。
这个定位决定了Flowing的API设计会偏向"底层原语"而不是"高层抽象"。它可能不会给你一个create_agent()就完事，而是让你显式地声明Agent的执行图、状态schema、容错策略。这对新手来说门槛稍高，但对需要精细控制的复杂场景来说，这种显式性是必要的。
3. Flowing的调度内核：执行图、状态机与并发控制
3.1 执行图模型：把Agent交互画成一张有向图
Flowing最核心的抽象是执行图（Execution Graph）。每个Agent的一次完整处理流程被建模为一张有向图，节点是执行单元（比如一次模型调用、一次工具调用、一次状态读写），边是依赖关系。
这个模型的好处是，它把"执行顺序"从代码逻辑里抽离出来，变成运行时可分析、可调度的数据结构。举个例子，如果节点B依赖节点A的输出，那么运行时就知道B必须等A完成才能开始；如果节点C和节点D之间没有依赖，运行时就可以并行执行它们。
我实测下来，这种显式建模在复杂交互场景下特别有用。比如前面提到的"单轮多意图"场景，你可以把三个意图分别建模为三个子图，然后声明它们之间的依赖关系。运行时会自动做拓扑排序，确定哪些可以并行、哪些必须串行。这比在代码里手写if-else判断执行顺序要清晰得多，也更容易调试。
执行图的另一个好处是可观测性。因为每个节点的执行状态、输入输出、耗时都被运行时记录，你可以很直观地看到整个流程在哪里卡住了、哪个节点耗时最长、哪个节点的输出不符合预期。这在排查复杂交互问题时非常关键——手写Agent出问题时，你往往只能靠打日志，而日志是线性的，很难反映并发和依赖关系。
3.2 状态机：显式状态比隐式对话历史可靠得多
Flowing的状态管理采用显式状态机模型。每个Agent实例维护一个状态对象，这个对象的结构由开发者通过schema声明。运行时保证：任何状态变更都必须通过事务接口进行，要么全部成功，要么全部回滚。
这和"把状态塞进prompt"的做法有本质区别。塞进prompt的状态是隐式的、非结构化的，模型需要从自然语言里"猜"当前状态是什么。而显式状态是结构化的、可验证的，运行时可以精确知道当前状态的值，也可以做类型检查和约束校验。
我踩过的一个坑是：早期用对话历史传递状态时，模型经常把"用户之前说要去上海"和"用户现在说要去杭州"搞混，因为它无法区分哪个是当前有效状态、哪个是历史状态。改成显式状态机后，每次状态变更都是明确的赋值操作，模型只需要读取当前状态对象，不再需要从历史里推断。这个改动让状态相关的错误率下降了大概七成。
Flowing的状态机还支持版本化。每次状态变更都会生成一个新版本，旧版本保留。这在需要回滚的场景下很有用——比如某个工具调用失败后，你可以把状态回滚到调用前的版本，然后尝试另一条执行路径。版本化也方便做审计，你可以追溯状态是怎么一步步变成现在这样的。
3.3 并发控制：乐观锁与冲突解决
多Agent协作场景下，并发读写状态是常态。Flowing采用乐观锁策略：每个状态变更操作都会检查状态版本号，如果版本号在执行期间被其他操作修改过，就拒绝本次变更并触发重试或冲突解决流程。
为什么用乐观锁而不是悲观锁？因为Agent场景下，状态读操作远多于写操作，而且写操作的冲突概率通常不高。悲观锁会导致大量不必要的等待，降低吞吐。乐观锁在冲突少的情况下性能更好，冲突多的时候通过重试机制也能保证正确性。
冲突解决策略是可配置的。最简单的策略是"后写覆盖"，但这在复杂场景下容易丢数据。Flowing支持更细粒度的策略，比如"字段级合并"——如果两个操作修改的是状态对象的不同字段，就自动合并；如果修改的是同一字段，则触发冲突回调，由开发者决定怎么处理。
注意：乐观锁的重试次数需要根据业务场景设置。重试次数太少会导致高冲突场景下大量失败，太多则可能导致长时间占用资源。我一般建议从3次开始，根据实际冲突率调整。
3.4 执行图的动态调整
复杂交互的一个特点是，执行路径往往不是完全预先确定的。比如用户输入可能触发不同的工具调用分支，某个分支可能又触发新的子任务。Flowing支持动态执行图：在运行时根据中间结果动态添加节点和边。
这个能力很关键，因为很多真实场景无法在启动时就把整张图确定下来。比如一个客服Agent，用户的问题可能涉及订单查询、退款、投诉等多个方向，具体走哪条路径取决于用户的具体描述和中间查询结果。动态执行图让运行时可以在执行过程中"生长"出新的分支，而不是要求开发者预先枚举所有可能路径。
动态调整也带来了调度复杂度的上升。Flowing的做法是维护一个"待执行节点队列"，每次有节点完成或新节点加入时，重新计算可执行节点集合。这个计算过程需要保证不会引入循环依赖，也不会让某个节点永远等待。运行时会对执行图做环检测，如果发现动态添加的边导致环，就拒绝这次添加并报错。
4. 容错设计：当工具调用失败、模型超时、上下文溢出时怎么办
4.1 工具调用失败的分类与处理策略
工具调用失败是Agent运行时最常见的问题。我把失败分成三类，每类的处理策略不同。
第一类是瞬时失败，比如网络抖动、服务临时不可用。这类失败通常重试就能解决。Flowing支持为每个工具节点配置重试策略，包括重试次数、退避算法、超时时间。我一般建议对查询类工具配置3次重试，指数退避，初始间隔500毫秒；对写入类工具则要谨慎，因为重复写入可能产生副作用，需要工具本身支持幂等。
第二类是永久失败，比如参数格式错误、权限不足。这类失败重试没有意义，应该直接走降级路径。Flowing允许为每个节点声明降级节点，当主节点永久失败时，自动切换到降级节点执行。比如一个高级搜索工具失败后，降级到基础搜索工具。
第三类是部分失败，比如批量操作中部分成功部分失败。这类失败最麻烦，因为状态可能处于不一致的中间态。Flowing的做法是要求工具声明自己的事务语义：如果工具支持事务，运行时会在失败时触发回滚；如果不支持，运行时会把失败信息记录到状态里，由后续逻辑决定怎么补偿。
4.2 模型调用的超时与降级
模型调用超时是另一个高频问题。尤其是在多Agent协作场景下，一个子Agent的模型调用超时可能导致整个流程卡住。Flowing对模型调用节点设置了强制超时，超时后触发降级。
降级策略可以配置为：切换到更快的模型、返回缓存的相似结果、或者直接返回一个"暂时无法处理"的兜底响应。具体选哪种取决于业务场景。比如代码审查场景下，超时后可以降级到规则引擎做基础检查；客服场景下，超时后可以转人工。
我实测发现，模型调用的超时时间设置很讲究。设太短，正常的长文本生成会被误杀；设太长，异常情况下用户等待时间过长。我的经验是：根据P95响应时间设置，通常是P95的1.5到2倍。同时要监控超时率，如果超时率超过5%，说明要么模型服务不稳定，要么超时时间设置不合理。
4.3 上下文溢出的预防与压缩
上下文溢出是复杂交互的必然问题。对话轮次一多，或者工具返回结果一大，上下文窗口就不够用了。Flowing提供了几种应对策略。
第一种是滑动窗口，只保留最近N轮对话。简单但粗暴，可能丢失重要信息。
第二种是摘要压缩，把较早的对话用模型压缩成摘要。这个策略效果好但成本高，因为压缩本身需要调用模型。
第三种是结构化提取，把对话中的关键信息提取到显式状态里，然后丢弃原始对话。这是Flowing推荐的方式，因为它和显式状态机模型天然契合。对话历史只作为"原始记录"保留，实际执行时只读取状态对象，上下文占用大幅降低。
提示：结构化提取的关键是设计好状态schema。schema太粗，提取不出足够信息；schema太细，提取过程本身就很复杂。我一般建议从业务实体出发设计schema，比如订单场景下的"订单号、状态、金额、时间"这几个核心字段。
4.4 死锁检测与打破
多Agent协作场景下，死锁是可能发生的。比如Agent A等待Agent B的输出，Agent B又等待Agent A的输出。Flowing的运行时会对执行图做周期性死锁检测，如果发现循环等待，就触发打破机制。
打破机制通常是：选择一个优先级较低的等待边，强制超时，让对应的Agent走降级路径。选择哪条边来打破，可以基于优先级、等待时长、或者业务规则。Flowing允许开发者配置打破策略，默认策略是打破等待时间最长的边。
死锁检测本身有开销，所以Flowing默认只在检测到"所有可执行节点都处于等待状态超过阈值时间"时才触发。这个阈值可以配置，我一般建议设为正常执行时间的3到5倍。
5. 记忆与状态：Agent如何在多轮交互中保持一致性
5.1 短期记忆、长期记忆与工作记忆的区分
Flowing把Agent的记忆分成三类，每类的存储和访问方式不同。
工作记忆是当前执行图内共享的状态，生命周期仅限于一次完整处理流程。它存在内存里，读写最快，但流程结束后就销毁。工作记忆适合存放中间计算结果、临时变量。
短期记忆是跨轮次但有时效性的状态，比如当前会话的上下文。它通常存在内存或轻量级存储里，有TTL。短期记忆适合存放"用户当前正在处理的任务"这类信息。
长期记忆是持久化的、跨会话的状态，比如用户偏好、历史交互摘要。它存在数据库或向量存储里，读写较慢，但生命周期长。长期记忆适合存放"用户是谁、喜欢什么、之前遇到过什么问题"这类信息。
这个三分法和人类记忆的认知模型是对应的。工作记忆像你脑子里正在算的数学题，短期记忆像你今天早上开会的内容，长期记忆像你的生日和家庭住址。区分这三类的好处是，你可以针对不同记忆类型采用不同的存储、压缩、检索策略，而不是把所有东西都塞进一个"记忆库"里。
5.2 记忆写入的时机与去重
记忆写入的时机很关键。写太频繁，存储压力大且容易产生冗余；写太少，可能丢失重要信息。Flowing的策略是：在工作记忆发生关键变更时，触发短期记忆的写入；在会话结束时，触发长期记忆的写入。
关键变更的定义可以配置。比如状态机中某个核心字段发生变化、某个工具调用返回了重要结果、用户明确表达了偏好。这些事件会触发记忆快照。
去重是另一个重要问题。多轮交互中，用户可能反复表达同一个偏好，如果每次都写入长期记忆，就会产生大量重复。Flowing在写入长期记忆前会做相似度检查，如果新记忆和已有记忆的相似度超过阈值，就合并而不是新增。相似度计算可以用向量检索，也可以用规则匹配，取决于记忆的结构化程度。
5.3 记忆检索的相关性与时效性权衡
记忆检索的挑战在于，既要找到相关的记忆，又要考虑时效性。一个用户三年前说喜欢某个品牌，和昨天说喜欢某个品牌，权重应该不同。
Flowing的检索策略是相关性分数乘以时效性衰减因子。相关性分数通过向量相似度或关键词匹配计算，时效性衰减因子根据记忆的时间戳计算，越久远的记忆衰减越多。衰减曲线可以配置，我一般建议用指数衰减，半衰期根据业务场景设置——快消品场景可能设为一周，金融场景可能设为一个月。
检索结果的数量也要控制。检索太多会占用上下文，检索太少可能遗漏关键信息。Flowing默认返回Top-K，K可以配置。我的经验是，对于大多数场景，K设为3到5比较合适，既能覆盖主要相关信息，又不会让上下文过于臃肿。
5.4 记忆冲突的检测与解决
当新记忆和旧记忆冲突时，怎么处理？比如用户之前说"预算5000"，现在说"预算8000"。Flowing的做法是：不直接覆盖，而是保留两个版本，并在状态里标记冲突。然后由业务逻辑决定怎么处理——可以是"以最新为准"，也可以是"触发澄清对话"。
这个设计的原因是，记忆冲突往往反映了真实世界的变化，直接覆盖可能丢失重要信息。比如用户预算变化可能意味着需求变化，如果直接覆盖，Agent就不知道用户曾经有过不同的预算，可能错过一些重要的上下文。
冲突检测可以在写入时做，也可以在读取时做。写入时检测的好处是能及时发现问题，读取时检测的好处是能根据当前上下文判断冲突是否重要。Flowing两者都支持，具体用哪种取决于场景。
6. 轻量级的边界：Flowing不做什么，以及为什么
6.1 不内置模型：运行时和模型的解耦
Flowing不内置任何模型，也不绑定任何模型提供商。它通过一个抽象的模型接口和外部模型通信。这个设计的原因是：模型迭代太快，运行时框架不应该绑定特定模型。
我见过一些框架把模型调用封装得很深，结果模型升级后框架不兼容，或者想换模型时发现要改大量代码。Flowing的解耦设计让模型切换变成配置变更，而不是代码重构。
这个设计也意味着Flowing不负责prompt管理、不负责模型参数调优。这些是上层应用的事。运行时只关心"调用模型、拿到结果、处理异常"，不关心你用什么prompt、用什么温度参数。
6.2 不内置存储：状态持久化的可插拔设计
Flowing不强制使用特定的存储后端。它定义了一个存储接口，开发者可以接入内存、Redis、PostgreSQL、或者任何其他存储。默认提供一个内存实现用于开发和测试，生产环境需要自己接入。
这个设计的考虑是：不同场景对存储的要求差异很大。有的场景要求低延迟，有的要求高持久性，有的要求强一致性。如果框架强制一种存储，就会限制适用场景。可插拔设计让开发者根据实际需求选择。
代价是，开发者需要自己处理存储的可靠性、备份、迁移等问题。Flowing提供了一些最佳实践文档，但不提供开箱即用的生产级存储方案。这是"轻量级"的取舍——框架只做核心的调度和容错，周边设施交给生态。
6.3 不内置可观测性后端：只提供埋点接口
Flowing不内置日志、指标、追踪的后端，但提供了完整的埋点接口。每个节点的执行开始、结束、异常、状态变更都会触发埋点事件，开发者可以接入自己的可观测性系统。
这个设计的原因是：可观测性后端的选择高度依赖现有基础设施。有的团队用Prometheus+Grafana，有的用ELK，有的用云厂商的APM。框架强制一种方案会带来集成成本。提供埋点接口，让开发者自己决定怎么消费这些事件，更灵活。
我一般建议至少接入三个维度的观测：执行图的整体耗时和成功率、各节点的耗时分布和失败率、状态变更的频率和冲突率。这三个维度能覆盖大部分运行时问题。
6.4 轻量级的代价与适用边界
轻量级不是没有代价的。Flowing不提供开箱即用的分布式部署方案，不提供自动扩缩容，不提供多租户隔离。这些都需要开发者在运行时之上自己构建。
所以Flowing适合的场景是：团队有一定的工程能力，需要精细控制Agent运行时行为，且不希望被框架绑定。如果你的团队希望开箱即用、不想碰底层细节，那平台类产品可能更合适。如果你的场景非常简单，单轮问答就能解决，那也用不着Flowing。
我个人的判断标准是：当你发现手写Agent的调度和容错代码超过业务逻辑代码时，就该考虑引入运行时框架了。Flowing是这类框架里比较轻、比较可控的一个选择。
7. 从Demo到生产：接入Flowing的实操路径与踩坑记录
7.1 第一步：把现有Agent逻辑拆成执行图
接入Flowing的第一步不是写代码，而是把你现有的Agent逻辑画成一张执行图。这个过程本身就是一次很好的梳理，你会发现很多之前没注意到的隐式依赖和潜在冲突。
具体做法是：列出所有执行单元（模型调用、工具调用、状态读写），然后标注它们之间的依赖关系。依赖关系分两种：数据依赖（B需要A的输出）和控制依赖（B必须在A之后执行，但不一定需要A的输出）。Flowing两种都支持，但数据依赖可以并行优化，控制依赖只能串行。
我踩过的一个坑是：一开始把所有东西都标成控制依赖，结果执行图变成一条直线，完全没有并行。后来仔细分析发现，很多步骤之间其实没有真正的依赖，只是代码里写成了顺序执行。改成数据依赖后，并行度提升了不少，整体耗时下降了约四成。
7.2 第二步：定义状态schema与迁移策略
状态schema的设计是接入过程中最需要仔细考虑的部分。schema太简单，运行时无法做有效的状态管理；schema太复杂，维护成本高。
我的经验是：从业务实体出发，而不是从代码变量出发。比如客服场景下，业务实体是"用户、订单、工单"，那schema就应该围绕这三个实体设计。代码里的临时变量、循环计数器这些，不应该进schema，它们属于工作记忆，不需要持久化。
迁移策略也要提前考虑。如果schema需要变更（比如新增字段），旧的状态数据怎么处理？Flowing支持schema版本化，但迁移逻辑需要开发者自己写。我建议在schema设计时就预留一些扩展字段，避免频繁变更。
7.3 第三步：配置容错策略并做故障注入测试
容错策略的配置不能拍脑袋，需要基于实际故障数据。我的做法是：先上线一版基础策略（重试3次、超时P95的1.5倍），然后通过故障注入测试来验证和调优。
故障注入测试的做法是：人为让某些工具调用失败、让模型调用超时、让状态写入冲突，观察运行时的行为是否符合预期。Flowing提供了一些测试工具来模拟这些故障，但更可靠的做法是在测试环境里真的把依赖服务停掉或限流。
我实测发现，很多容错策略在纸面上看起来没问题，但实际跑起来会发现重试次数不够、降级路径也有问题、或者冲突解决策略导致数据丢失。故障注入测试能提前暴露这些问题。
7.4 第四步：观测接入与性能基线建立
上线前必须建立性能基线。需要观测的指标包括：端到端耗时、各节点耗时、成功率、重试率、状态冲突率、上下文占用率。这些指标要持续监控，任何一项异常波动都可能是问题的前兆。
我一般会设置几个告警阈值：端到端耗时超过基线2倍、成功率低于95%、重试率超过10%、状态冲突率超过5%。这些阈值不是绝对的，需要根据业务场景调整。但有了基线，你就能在问题扩大之前发现它。
7.5 常见坑位清单
最后列几个我在接入过程中踩过的坑，供参考。
坑一：状态schema设计过细。一开始把每个中间变量都放进schema，结果状态对象巨大，每次读写都很慢。后来精简到只保留业务实体，性能明显改善。
坑二：重试策略没有区分工具类型。对写入类工具也配置了自动重试，结果产生了重复写入。后来改成写入类工具只重试幂等操作，非幂等操作走人工补偿。
坑三：死锁检测阈值设得太低。正常的长耗时操作被误判为死锁，触发了不必要的降级。后来把阈值调到正常执行时间的5倍，误报率大幅下降。
坑四：记忆检索没有做时效性衰减。三年前的记忆和昨天的记忆权重一样，导致Agent经常引用过时信息。加上时效性衰减因子后，这个问题基本消失。
坑五：没有做执行图的可视化。出问题时只能看日志，很难定位。后来接入了执行图的可视化工具，能直观看到每个节点的状态和耗时，排查效率提升很多。
这些坑的共同点是：它们都不是Flowing本身的问题，而是使用方式的问题。运行时框架提供了能力，但怎么用好这些能力，还是需要开发者根据具体场景做判断。这也是为什么我一直强调，运行时框架不是银弹，它只是把脏活累活标准化了，业务逻辑的正确性还是得靠开发者自己保证。
