01.1 我踩过的最疼的坑
去年我帮一个朋友搭客服机器人。他用官方 SDK 直接调模型 API，把"先查库存、再判断意图、最后回复"全写死成代码。
写了 800 行流程控制。改一个需求，全要重写。
模型越强，这套写死的逻辑越脆。现实一变，脚本就崩。
标叔的经验：手写流程只适合窄而固定的活。
我做过一个文档分类脚本，写死 5 步。上线第 3 天，用户传了个格式异常的文档，整个流程报错。模型其实能处理，但被我的脚本卡死了。
01.2 旧方案 vs 新方案
Flue 的思路完全相反。你不再写"怎么干"，而是给模型一个"环境"，让它自己找路。
| 维度 | 手写流程脚本 | Flue（Harness 驱动） | 标叔的结论 |
|---|---|---|---|
| 谁决定步骤 | 你写死 | 模型自己选 | 让模型掌舵 |
| 改需求成本 | 重写流程 | 改指令/工具 | Flue 省 10 倍 |
| 抗意外能力 | 弱，一变就崩 | 强，模型能绕路 | 现实不按脚本走 |
| 适合场景 | 窄而固定 | 开放、长尾 | 看你的活儿 |
重点看：最后一列"标叔的结论"。
这些数字背后的信号就一个：你越想让 Agent 干复杂活，越不能写死流程。
01.3 一个公式讲清 Flue
先给结论：Agent = 模型 + 马具（Harness）。
模型你熟。马具是啥？英文叫 harness，原意是"给马套上的挽具"。
类比级联一下：
- 模型是马的大脑。它只想事，不会动。
- 马具是缰绳、鞍、眼罩。它决定马能去哪、能看啥、能拉啥。
- 没有马具的马，是罐子里的大脑。再聪明，也动不了。
Flue 就是那套马具。它用 TypeScript 写成，给你现成的：记忆、工具、技能、沙箱。
核心建议：先把"模型"和"马具"分开想。
很多人学 Agent 框架卡住，是因为把"模型能力"和"运行环境"混在一起。分开后，Flue 一切都顺了。
01.4 适合谁，不适合谁
- 你是 TypeScript 开发者，想用代码搭 Agent → 适合。
- 你要一个开箱即用的聊天界面 → 不太适合，Flue 是 headless（无界面）。
- 你只想要一句话调模型 → 太重了，直接用 SDK 更轻。
下一章，我带你 10 分钟跑通第一个 Agent。不讲虚的。