Flue：用 React Hooks 的写法写 AI Agent
阅读时间: 大约 8 分钟
Flue：用 React Hooks 的写法写 AI Agent
写 Agent 的方式正在分化：一类是”提示词工程 + 手写循环”，一类是把它当成正经的有状态程序来工程化。Flue 走的是后者——这个由 Astro 团队推出的开源 TypeScript Agent 框架，在 2.0 版本引入了”Agent Hooks”，让你用写 React 组件的思路（useState、useEffect 的同构物）来定义 Agent。本文基于 flueframework.com 官网做分析。
一、它是什么
官网把 Flue 定位为 “The Open Agent Framework”，口号是 “Build durable AI agents with Flue’s programmable TypeScript harness. Write once, deploy anywhere, use any LLM.” 它自称是一个可编程的 TypeScript harness（运行骨架），而不是一个具体 Agent 产品。
最反直觉的是它的 API。官网示例：
export function MyAssistant() {
const [count, setCount] = usePersistentState('count', 0);
useAgentStart(() => setCount((n) => n + 1));
useModel('moonshot/kimi-k2');
return `You are a helpful assistant. This conversation has ${count} messages.`;
}usePersistentState、useAgentStart、useModel——这套命名几乎是照搬 React Hooks 的心智模型。对前端工程师来说，这意味着状态、副作用、模型选择都变成了”声明式 hook”，而不是自己去管理的命令式循环。
二、底层：跑在 “Pi” 这个 harness 上
官网明确说明：Flue is powered by Pi, the open agent harness used by OpenClaw。也就是说 Flue 并不是从零造引擎，而是把 Pi 这个已经被 OpenClaw 等项目使用的开源 harness 包装成更友好的 TypeScript 框架。Pi 提供 Durable Streams、Vite 工具链和一个可插拔的 Sandbox API。
这种”上层框架 + 成熟底层 harness”的分层，和前端框架建立在 React 运行时之上的思路一致。
三、核心机制：持久化流（Durable Streams）
官网花了很大篇幅讲一个论点：“Agents can’t die when the server goes down.”
具体做法是：Flue 把每个 session 的每一步都记录到一条持久化流里；当进程崩溃、重启或重新部署后，runtime 回来时会自动恢复被中断的 session，客户端重连时不必从头开始。官网用一个”0 agents online”的交互演示来佐证：人为打断（disrupt）运行中的 Agent，任务仍能接续。
它把整个技术栈分成两层：
- Runtime 层：沙箱、数据库、部署；
- Harness 层：session、工具、skill。
四、功能清单（官网可核实）
官网列出的能力包括：
- Agents：有状态、可通过 HTTP 寻址、跨对话保持上下文；
- Workflows：Agent 就是函数，可用
flue run在本地/CI/自己的后端跑，也可编排进 Cloudflare Workflows、Inngest； - Sandboxes：Agent 安全地执行命令、编辑文件；
- Persistent State / Subagents / Tools / Skills：持久状态、子代理委派、自定义工具、可按需加载的技能包；
- MCP Servers：通过 Model Context Protocol 接入上千工具；
- Observability：session trace 导出到 OpenTelemetry、Braintrust、Sentry；
- Chat 接入：Slack、Teams、Discord、GitHub 等。
五、口径偏差与局限
- “Durable”是工程保证，不是性能承诺：持久化流解决的是崩溃恢复（正确性/可用性），并不意味着低延迟或低成本——每一步都落流本身有写入开销，官网没有给出吞吐或成本数字。
- “Powered by Pi”意味着生态绑定：框架能力上限受 Pi 这个底层 harness 约束，遇到 Pi 不支持的运行时（如非 JS 环境）就无法”write once, deploy anywhere”。
- “Open”是框架开源，托管运行时另算：沙箱、Durable Streams 后端如何自部署、是否依赖托管服务，官网首页未交代清楚，需要查文档确认。
- 项目库点评的保留：它的 API 设计有创新，但仍偏向”编程”范畴；在模型能力主导的当下，这种框架更适合”由模型而非人类开发者去写业务逻辑”的场景——即作为给编码 Agent 用的底层 harness，而非直接给人写业务的银弹。
- 配图说明：官网首页以营销文案与集成 Logo 为主，未提供架构图或基准图表，故本文采用首屏截图，信息集中在其定位与 Hooks 风格 API 上。
六、适用 / 不适用
适合：
- 已经熟悉 React/Hooks 心智、想快速把 Agent 工程化的 TypeScript 团队；
- 需要 Agent 能扛住重启、崩溃、重新部署（如跑在 Cloudflare Workers 这类短生命周期 runtime 上）的场景；
- 想要一套从沙箱、状态到可观测性的完整栈，而不是自己拼装。
不适合：
- 偏好 Python 生态、或团队没有前端经验的项目；
- 只需要一个简单的一次性 prompt→response，不需要有状态持久化的场景；
- 对”底层 harness 由第三方维护”有顾虑、要求完全可控的团队。
七、它意味着什么
Flue 的信号在于：Agent 开发正在被”前端工程化”的范式收编——声明式状态、副作用 hook、崩溃恢复、可观测性，这些过去属于 Web 应用的工程实践，正在成为 Agent 框架的标准配置。它是否成功，取决于”用 Hooks 写 Agent”这层抽象是否真的比命令式循环更省心智；目前看是一个有趣但仍需场景验证的尝试。