你的 AI Agent 不是工具，是一块无限画布：RL Nabors 的反常识示范

如果你还把 Agent 当成“会自动点按钮的脚本”，这支视频会让你非常不舒服。RL Nabors 在 AI Engineer 的演示里，用 Claude 和一套工具链，展示了一个反直觉的观点：真正强大的 Agent，不是执行器，而是一块可以无限扩展的认知画布。

最反直觉的一点：Agent 不是流程，而是“空间”

视频一开始并没有急着讲技术，而是用一种略带吐槽的方式铺垫情绪："Everyone online was edgy." 这句话其实点中了当下 Agent 讨论的真实状态——大家都在争谁的框架更自动、谁的 Demo 更炫，但 RL Nabors 直接把桌子掀了。

他的核心判断是：如果你把 Agent 理解成一条固定流程，那你一开始就限制了它的上限。在他的定义里，Agent 更像一个“无限画布”（infinite canvas）：你可以不断往上加工具、加上下文、加行为层，而不是提前把路径写死。

这也是为什么他反复强调：不要急着设计完美的 workflow。真正有生命力的 Agent，往往是先能“活下来”，再慢慢长出复杂结构的。这个思路，对习惯了流程图和状态机的工程师来说，其实相当刺耳。

从 Transports 到 Tools：他是怎么“喂养”Claude 的

真正的干货从 transports 开始。RL Nabors 并没有把重点放在某一个花哨的 Agent 框架上，而是拆解了一个更底层的问题：模型到底是通过什么方式，与外部世界发生关系的？

在他的示例里，Claude 并不是一个孤立的聊天模型，而是被一层层工具包围：有的工具只返回“纯数据”，有的工具会触发真实动作，还有的工具本身就是另一个系统的接口。他特别强调了一点：工具的返回值设计，比你想象中重要得多。

如果工具返回的是难以解释的混合结构，Agent 的认知负担会急剧上升；反过来，越是“朴素”的返回，越容易被模型稳定使用。这也是他反对过度封装的原因之一——封装不是为了优雅，而是为了让模型少犯错。

一个危险但真实的提醒：别再滥用浏览器型 Agent

视频中段，他抛出了一个让不少人尴尬的观点：很多人还在用浏览器自动化，其实只是因为“看起来很酷”。在他看来，这类 Agent 的成功率、可复现性和可维护性，都远低于大家的心理预期。

RL Nabors 的态度很明确：如果你的 Agent 需要频繁“像人一样”点网页，那大概率说明系统设计出了问题。不是浏览器不行，而是它应该是最后的兜底方案，而不是默认选项。

这个判断背后，其实是一种成熟的工程观：Agent 的 wow moment 不在于它看起来多像人，而在于它能否在无人盯着的情况下，稳定地产生结果。视频里那句脱口而出的 "Yay！ That's the wow."，更像是一种反讽。

为什么说这是给 AI 从业者的一次“降维提醒”

整支视频看完，你会发现 RL Nabors 几乎没怎么炫技。他更多是在不断踩刹车：别做这个、别急那个、别被 Demo 带跑偏。对很多已经在做 Agent 产品的人来说，这反而是最值钱的部分。

他展示的不是一个“最终形态”的 Agent，而是一种长期可生长的思路：从最小可用开始，用工具慢慢堆出能力，让模型在一个干净、可解释的环境里学习如何行动。这种耐心，在当下追逐发布节奏的环境里，显得格外稀缺。

总结

如果你正在做 Agent，这支视频真正想传达的不是某个技巧，而是一种判断标准：你的 Agent，是不是还能继续长？还是一开始就被你画死在画布的一角。

行动建议很简单：回去看看你现在的 Agent 设计，删掉一半你“以为将来会用到”的流程，多花时间打磨工具接口和返回结构。短期内它可能不够炫，但长期来看，这正是让 Agent 具备复利的关键。

最后留一个问题：当模型能力继续提升时，你的 Agent 会因此变强，还是反而暴露出更多结构性限制？答案，取决于你今天画下的那块“画布”。

关键词： AI Agent， Claude， 工具调用， Agent 设计， AI 工程

事实核查备注： 需要核查：视频中 RL Nabors 的原话表述；transports 与 tools 的具体定义是否与视频完全一致；Claude 在示例中的具体角色定位；视频发布时间与标题准确性