面向智能体的 React：Astro 创建者将 Hooks 引入其元框架 Flue
React for Agents：Astro 之父把 Hooks 带进了他的元框架 Flue
面向开发者的 Agent 框架目前仍处在非常早期的阶段，今年发布的 Vercel eve 和 Fred Schott 的 Flue 算是率先定下基调的两个项目。
Schott 是前端框架 Astro 的创造者，他创立的公司今年 1 月被 Cloudflare 收购。他刚刚发布了 Flue 2，这是该框架的首个稳定版本，其核心是 React 风格的“Agent Hooks”。
在 Flue 中，一个 Agent 就是一个 JavaScript 函数。这个函数“在每一轮对话时重新渲染”——也就是每次调用模型之前都会执行一次。之所以引入 Hooks，是因为 Schott 发现 React 的可组合性非常适合 Agent 开发。
“我最初发推说我们正在打造‘Agent 界的 Astro’或‘Agent 界的 Next.js’，”他告诉我们，“但后来我意识到：也许根本还没人做出‘Agent 界的 React’。”
编者注：我们上次聊到“Agent 界的 React”这个话题，是在采访 Sierra CEO、OpenAI 董事会主席 Bret Taylor 的时候，他说：“我们还在摸索哪些 Agent 是响应式的，目前尚无定论……我们大致还处在 Agent 的 jQuery 时代，离 React 时代还远。”
Hooks 用 TypeScript 编写。根据 Flue 2 的发布公告，它们“让你构建出动态的 Agent，能够管理自身状态、监听 Agent 生命周期事件，甚至可以在运行时动态挂载不同的资源和能力来增强自己”。
Flue 2 内置了 16 个 Hooks，包括 useSkill()、useTool()、useSubagent()，也支持自定义 Hooks。
Hooks 给开发者带来的核心变化在于：它让 Agent 的配置可以随着对话或工作流的推进而动态调整，从而使 Agent 变得更灵活。Schott 说，这是构建“真正的客服机器人、真正的工单分类机器人”所必需的，因为这类场景无法事先把所有配置写死。Agent 不能是静态的——它必须根据用户的需求或实际情境实时调整。Agent Hooks 正是把这些能力带给了 Flue。举个例子，一个客服 Agent 可以在验证完用户身份之后，再引入一个账户管理工具。
基于文件的魔法是一种反模式
Schott 自 5 月初公开发布 Flue 1 以来，对如何构建 agent 框架的想法迅速演变。最初，他想把现有的 Web 框架概念应用到他的新 agent 框架中。他以基于文件的路由为例。“所以我们有点天真地把那套东西搬到了 Flue 上，心想——太好了，我可以把你的五个 agent 放进五个文件里，它们就对应五个路由。但对很多用 Flue 构建的人来说，尤其是较大的客户，他们整个公司就是一个 agent，他们根本不关心路由。只有一个 agent。”因此，在第一批 Flue 用户展现出这些早期模式后，组合性成了 Schott 最关心的问题。这让他回到了 React。“从 Flue 2 的 API 可以看出，我们更多地借鉴 React，而不是 Astro 或 Next.js——它更少关注路由和这些网站概念，而更关注在基础层面上，如何用许多不同的东西组合出一个 agent？”
Flue 的核心主张：agent 需要一个 harness
Flue 的一个关键概念是，agent 必须有一个 harness——也就是说，它处于一个环境中，能够访问完成各种任务所需的上下文和能力。Schott 解释说：“不是由你和你的代码用脚本驱动 LLM、告诉它该做什么，而是把 agent 放进这个 harness 里，让它自己驱动自己、自己解决问题。”
Flue 构建在 Pi 之上，Pi 是一个开源的最小化 harness。本质上，Flue 是 Pi 的一种有主见的实现——添加了 Schott 认为对构建 agent 的开发者有用的功能。例如：Flue 2 中的托管 agent 现在使用构建工具 Vite 构建。事实上，Schott 将 Pi 的角色比作 Vite 在 Astro 底层所扮演的基础性角色。“我认为 Pi 可以扮演这个角色，它是一种恰当的抽象——它不会做太多事情，但提供了正确的 API，这样我们就可以在此基础上说：好吧，让我们用一种更有主见的方式来做得更多。”
基于 Pi 构建，意味着要承诺内置一个 agent harness。
用编码 agent 构建 Flue agent
Flue 项目始于今年早些时候，位于 Astro 仓库内部，最初是一个 issue 分流系统。一开始，它只是个由 LLM 驱动的脚本或工作流，负责审查 issue。但 Schott 解释说，后来它获得了在仓库中执行操作的能力。「它开始从仓库里的自动化工具，转变为想把 Claude Code 的体验做成无头、可托管，并能在云端运行。」正是在那时，「以 harness 为锚」的想法出现了。事实上，在 5 月初的 v1 发布文章中，Schott 将 Flue 描述为「像 Claude Code，但 100% 无头且可编程」。我本人也用 Claude Code 亲自试了试 Flue，它引导我完成了第一个 Flue agent 的搭建。Schott 证实，这正是许多开发者使用 Flue 的方式。「我们很大程度上就是在为他们而建，」谈到 AI 编码 agent 时他说。「我们整个上手流程就是——把这段提示词交给你的 agent，它会引导你走完流程。我们所有文档都支持 markdown。」
Flue 在 agent 开发技术栈中的位置
与 Flue 最接近的对比对象是 Vercel 的 eve，后者同样把 harness 视为根基。Vercel 和 Cloudflare 公开互怼是出了名的，但 Schott 对 eve 的评价却很慷慨。「我认为 eve 是直接竞争对手，」Schott 说。「它几乎同时出现，所以也抱持同样的观点：harness 是内置的。」Schott 还提到了他所说的「元老级 agent 框架」（OG agent frameworks），这些框架出现在 Flue 之前，因此并没有以 harness 为核心概念来构建。他列举了 Vercel 的 AI SDK、Cloudflare 的 Agents SDK，以及 Mastra（由打造 Gatsby 的同一团队开发，Gatsby 是一个早于 Astro 的 Web 框架）。虽然这些「元老级框架」如今都在添加 harness，但 Schott 认为那只是附加功能——而 Flue 和 eve 都是内置 harness。我问 Schott，Flue 与新兴的「元 harness」（如 Databricks 的 Omnigent，甚至可能是自我改进的 Exo harness）相比，处于什么位置。
另外，本周末我们还会发布与 Exo 联合作者 Alex Krentsel 的访谈；值得一看，里面还有关于 OpenClaw 架构的额外讨论。Schott 正确地指出，在这个早期阶段，人们对 meta-harness 这个词的含义本身就感到困惑。尽管如此，他认为，用一个统一的 API 来操作所有 harness 会让 Flue 的定位变得模糊不清。他的框架明确规定了 Flue 中技能（skills）如何工作、子代理（subagents）如何工作等等。正如他所说：“框架（Flue）和 harness 是紧密交织在一起的。”他个人觉得 meta-harness 的讨论很有意思，也玩过 Exo，但他说那是“一种不同的兴趣场景，与托管代理（hosted agents）并没有真正的关系”。
Cloudflare 的关联
在整个访谈中，Schott 多次提到可以利用他的雇主 Cloudflare 的工具和基础设施。但他也非常明确地表示，Flue 是一个“面向所有宿主（host）的开源框架”，正如他所说，他希望保持这种状态。他说：“最好的工具是那些凌驾于宿主之上的工具。这为最大规模的开发者采用和最大程度的创新打开了大门。”宿主可移植性是 Flue 的核心原则之一——也许这正是它与 Vercel 的 eve 之间的根本区别所在。虽然 eve 也可以自托管，但它针对 Vercel 的众多功能进行了优化。当然，这是 Vercel 的惯用做法，他们对 Next.js 也是这么干的。话虽如此，Vercel 自己也展示了 Flue 代理可以部署在 Vercel 上。所以两家公司可以很好地合作。
我还提到了 LangChain 新推出的 Managed Deep Agents 产品，作为市场上出现的托管代理平台的一个例子。然而，Schott 表示，托管代理产品目前不在 Flue 的路线图上。他说：“对我们来说现在还为时过早，我们只专注于打造最好的 harness。”
以下是在线查找 Flue 和 Fred 的链接；Richard 的账号是 @ricmac。这是我们为订阅者尝试的全新书面访谈系列——欢迎告诉我们你的反馈！