生产环境中的 Agentic AI：RanBot 带给我的十二个月

RanBot 最初是一个随手做的实验，后来变成了我每天真正在用的东西。想法很简单：一个 AI 机器人平台，让你用自然语言定义工作流，系统自动负责执行。不需要写代码，不需要维护集成——描述你想做的事，让 Agent 去处理。

简单的想法，在实践中总是更复杂。

RanBot 到底是什么

核心上，RanBot 是一个多 Agent 编排平台。你创建”机器人”——每个机器人是一组指令、一组工具（网页搜索、API 调用、文件操作、通知），加上一个触发器（定时、Webhook 或手动）。机器人运行时，有一个 LLM 负责推理，加上一套可以调用的工具来与外部世界交互。

我们设计的使用场景：竞争对手监控（每日检查竞品定价）、内容摘要（筛选特定分类新闻生成早报）、数据补全（给一批公司名称查询最近的融资信息）、工作流自动化（当某个 Slack 频道收到含关键词 X 的消息时，执行 Y）。

这些都不是新颖的想法，RanBot 的价值在于尝试让这些功能在不写代码的前提下可用。

上线三周后，一个做竞品价格监控的机器人开始每分钟发出数百次 API 调用。导火索是一个限流错误——机器人收到 429 响应后，没有退避，而是立刻重试，再次得到 429，并把反复的失败解读为一个信号：需要更努力地尝试。于是它加快了重试频率。

我们叫它”恐慌循环”。Agent 没有”被限流了，等一下”这个概念，它只知道目标（获取数据）和工具（发 HTTP 请求）。工具一直失败，Agent 就一直调工具。

这是一个根本性的设计缺陷。我们考虑了 Agent 成功时应该做什么，却没有认真想过它系统性地失败时应该做什么。

修复方案是给 Agent 的上下文加入显式的失败处理——不只是工具层的错误，而是语义化的失败分类：“被限流了，等待后重试”、“认证失败，升级给人工处理”、“数据源不可用，跳过并记录日志”。Agent 需要一套描述不同失败模式的词汇，才能对它们做出正确反应。

十二个月下来，三个模式成了我们所有构建物的标配。

人工确认检查点。 对任何有真实副作用的操作——发邮件、发社交媒体、下订单——我们都加了一个确认步骤。Agent 起草操作内容，发送预览通知，等待明确的批准后再执行。感觉上像是破坏了自动化的意义，实际上这正是让自动化值得信任、真正被人使用的原因。审批一封邮件花三十秒，比手写它快多了。

最小化工具权限。 早期的机器人什么权限都有，后来的机器人只拥有必要的权限。一个监控竞品价格的机器人不需要写你数据库的权限，给了它就是在等事故。现在我们按机器人类型定义工具集，所有写入或删除能力都需要明确的理由。

显式状态日志。 Agent 做的每一个决策——每次工具调用、每个推理步骤、工作流里每一个分支——都要带足够的上下文记录下来，以便事后还原发生了什么、为什么这样。出了问题（一定会出），你需要能够回溯 Agent 的”思考过程”。没有这个，调试就是考古。

长周期任务。 目标距离当前上下文窗口越远，Agent 的表现越差。一个要花好几个小时做研究和综合的机器人会失去连贯性——忘掉早先找到的内容、反复访问同一个来源、自相矛盾。这不是用更好的提示词能解决的问题，而是 LLM 处理长序列的根本局限。

模糊的成功标准。 “帮我找关于 X 的好文章”比”找过去 30 天内关于 X 的、正文超过 1000 字的文章”难处理得多。成功条件越模糊，Agent 就越容易对”工作做完了”这件事产生幻觉式的自信。请精确定义完成条件。

对抗性内容。 网页不是中立的。有些页面专门设计来操控自动化系统——meta 标签里的提示词注入、误导性的结构化数据、告诉任何读到它的 AI 去执行特定操作的正文内容。一个浏览网页的机器人需要对此设防，而这比听起来要难得多。

“Agentic AI”这个框架可能会误导你，让你以为系统拥有像人一样的自主性。它没有。一个设计良好的 Agent 是一个具有非常丰富输入类型和大量内部循环的函数。它有目标和工具，但它没有人类那种判断力——它拥有的是规模化的模式匹配。

我构建过的最可靠的 Agent，都是那些做一件事、在严格约束下做的。最不可靠的，是我给了最大自由度的那些。如果你把 Agent 想象成自主工作者，这违反直觉；如果你把它们想象成函数，这非常合理。

RanBot 在 ranbot.online，欢迎去试试。最有意思的工作不在框架本身，而在于如何设计工作流，让 Agent 去做它们真正擅长的事。