只靠脑内记忆
如果任务进度只在进程内存里，服务一停，接下来该做什么就难说了。
重启可能丢上下文助手可以重启，
工作别跟着失忆。
Flue 像给 AI 员工一本断电不丢的工作簿：先记下任务，再干活，出故障后按记录恢复。
一个可编程的 TypeScript 智能体框架，不是新模型，也不是下载即用的聊天机器人。
Flue：持久工作簿
接收任务、会话、工具结果与状态留下记录，恢复时有据可查。
有记录才可恢复仍有失败出口三层结构：谁负责什么？
🧠
模型：负责推理
理解目标、选择工具、生成回复。Flue 可配置不同模型与提供商，但具体适配仍要确认。
更可靠的调度，不会自动让模型每个判断都正确。
🧰
Harness：负责行动循环
官方说明其基于 Pi，组织会话、工具、Skills 和子智能体，让助手能完成多步工作。
不是只调用一次模型接口，也不是只做一个聊天框。
📓
运行时：负责持续性
持久记录、排队、恢复，以及接入数据库、执行环境和部署平台。
恢复依赖正确配置的存储和宿主环境，不是脱离基础设施的魔法。
断电发生在哪里，处理就不一样
任务：调查一张工单，再调用工具处理它。切换故障点，看看哪些能继续、哪些必须核对。
教学模拟，不运行真实框架，也不会调用外部 API。这里的“恢复”不是 CPU 从崩溃指令原地继续。
Agent Hooks：像给员工按需发工具
用 TypeScript 函数声明一个智能体，再通过以 use 开头的 hook 配置能力：
useModel → 选谁来思考useTool → 给哪些业务工具usePersistentState → 记住阶段与事实useSandbox → 在哪里读文件、跑命令
像客服先只有“查订单”，进入已批准的处理阶段后再获得特定工具。资源 hooks 可随状态改变，不必把所有能力一开始都塞给它。
写法让人想起 React Hooks，但这是服务端 Agent 能力声明，不是网页组件；动态启用工具也不能代替后端真实授权校验。
为什么它不只是“自动重试”？
📮
先确认收到了什么
输入先持久接收，再开始模型工作。同一会话有队列和执行记录，客户端断线后可凭记录重新连接。
接收确认不等于业务已成功；最终状态也可能是 failed 或 aborted。
🪜
已完成的步骤不乱重做
持久工具可用 step.do 划出步骤。已记录完成的步骤读取旧结果，未提交完成的步骤才重新尝试。
外部操作成功但记录尚未落盘的窗口仍可能重复，需幂等设计。
🔌
接进你已有的系统
支持工具、MCP、Skills、子智能体与可观测性集成；官方提供 Node.js、Cloudflare 等部署路径。
它不是承包一切的通用工作流引擎，Agent 外的流程仍可能用平台工作流组织。
三个边界，比“永不丢任务”的广告更重要
① 会话存住了 ≠ 文件存住了
会话数据库保存记录，不自动保存沙箱文件。内存虚拟沙箱是临时的；要跨恢复保留文件，需要配置持久工作区。
② 工具叫“sandbox” ≠ 都有安全隔离
local() 直接使用宿主文件与进程，本身没有隔离边界。虚拟、远程和本地环境能力不同，应按风险最小化权限。
③ 记录一次 ≠ 对外操作绝不重复
付款、邮件、发消息是外部系统的副作用。用稳定的业务标识或幂等键防重，并核对不确定结果；框架不能替外部系统保证“只发生一次”。
适合什么任务？
需要多轮、多工具、跨事件继续推进的业务助手：工单调查、客服流程、代码任务或长时间后台处理。
如果只是一次问答，一个模型 API 也许就够了。Flue 的价值在于把“会做事”变成“出故障后仍有章可循地做事”。