夜雨聆风文档会自己"干活"：SnakeEats 让 Markdown 里的工具链自动跑起来
不是"又一个工作流引擎"而是让文档本身成为工作流
核心：不是"又一个工作流引擎"，而是让文档本身成为工作流——标记嵌入文字，扫描器自动执行，工具还能吐出新标记，让文档在执行中自己长出后续步骤。本文讲完整闭环体验，不做组件级技术堆叠。
你正在写一份销售数据分析报告，写到"按地区统计"时，在文档里敲下这一行：
@{llm_orchestrator|{"goal":"按地区统计销售额并生成对比表","target_stream":"report"}}
你点了保存，去做别的事。回来时，文档已经自己长出了这么一串：
@{query_db|{"sql":"SELECT region, SUM(revenue) FROM sales GROUP BY region"}}→ 华东 320万 | 华南 180万 | 华北 140万@{gen_chart|{"type":"bar","data":"[华东320,华南180,华北140]"}}→ 图表已生成 [查看]@{summarize|{"target":"以上数据"}}→ 华东贡献 50% 营收，建议优先投入华东市场
没有拖拽画布，没有配置工作流，没有写一行代码。一个高级目标被自动拆解成子任务、每个子任务被执行、结果写回原文——整份文档就是最终报告，也是完整执行记录。
这就是 SnakeEats（贪吃蛇）：扫描器像蛇一样在文档里前进，吃到标记就执行，执行吐出的新标记让文档变长，蛇游过自己新长的身体继续吃，直到整份文档不再有标记。
它解决的是什么问题
现有 AI 工具链有个共同的断层：
▎Claude Code / Codex
对话驱动，执行过程在聊天窗口里，聊完就"失忆"，中途无法介入，事后无法复现。
▎Dify / n8n
可视化画布，但"定义流程"和"执行流程"是两套东西，流程一复杂画布就失控。
▎Jupyter
代码和文本混排，但只能跑 Python，还得手动 Shift+Enter，不能自动串联。
SnakeEats 换了个思路：你正在写的文档，就是工作流本身。指令写在文字里，执行结果回流到原文里——文档既是计划、又是执行、又是记录、又是产物，四合一。
三个子系统，一个完整闭环
它由三个开源组件构成（各自已有独立介绍文章，这里只讲它们怎么协作）：
▎text-stream —— 文档的"地基"
带版本控制的文本流，支持实时订阅、按内容语义搜索、并发安全（详见《SnakeEats.text-stream：给多 Agent 之间装一条文本通道》）。
▎tool-registry —— 文档的"弹药库"
任何 Python/Shell/Node 脚本，注册后即可被文档标记调用；扫描器负责发现和执行标记（详见《SnakeEats.tool-registry：在文本里嵌入可执行代码》）。
▎stream-editor-py —— 文档的"驾驶舱"
多标签编辑器 + 扫描控制台 + 工具面板。
三者拼起来，就是"写文档 → 注册脚本 → 启动扫描 → 文档自己跑"的完整闭环。
它跑在你自己的机器上，你的 PATH 就是它的生态——不需要插件商店，Docker，任何生态。
三个真实跑通的场景
场景一：工具链级联——工具生成工具
@{chain_orchestrator|{"task":"查询北京天气","target_stream":"stream_a"}}
编排器分析任务后，自动往流末尾追加子工具标记：
@{chain_worker|{"type":"weather","city":"北京"}}
扫描器下一轮发现它，执行，结果写回。一个工具完成了"理解任务 → 拆分 → 调度子工具"的闭环——而且这发生在文档流里，每一步都可见、可暂停、可修改，不像 Agent 框架里的黑盒编排。
场景二：真实 LLM 编排——LLM 是文档里的一个普通工具
这是和 Claude Code 最本质的区别。Claude Code 把 LLM 当作唯一的决策者；SnakeEats 把 LLM 注册成一个工具，它读文档、看工具清单、分解任务，然后通过 insert_after() 把子任务标记原地插入当前扫描位置——不是追加到末尾排队，而是立即执行：
@{llm_orchestrator|{"goal":"清洗销售数据并生成分析报告"}} └─ LLM 读目标 + 工具清单 → 分解为 3-5 个子任务 └─ insert_after() 原地插入 → 扫描器立刻发现 → 立即执行 └─ 结果写回 → 文档继续前进
LLM 不是高高在上的聊天框，而是可以嵌入文档、就地展开工作的工具。决策点可以穿插在文档任意位置，人类随时暂停、改参数、继续。
场景三：交互式问答——文档在执行中实时生长
一个问答主控工具以后台进程运行，通过 stdin 收 T/F 指令。每收到一个 "T"，就往正在扫描的流里追加一道新题；扫描器发现、执行、显示结果。
你在和文档对话，文档在和你交互——这是 Jupyter 和 Dify 都做不到的形态。
体验上的三个杀手锏
▎随时暂停 = 人类永远在决策环中
AI 在文档里插了 10 个工具调用，执行到第 3 个你发现参数不对——暂停，改参数，继续。不用重跑，不用重新生成，断点续扫。
▎工具可审计
@{weather|{"city":"北京"}} 执行前什么样、执行后变成什么、参数是什么、用了哪个脚本——全在文档里，天然可回溯。企业最头疼的"AI 干了什么"，在这里是默认能力。
▎工具复用是"注册一次，全局调用"
团队里有人写了个数据清洗脚本，注册后，任何文档里写 @{clean_data|{...}} 就能用。门槛从"会编程"降到"会打字"。
诚实地说几句
▎文档即程序
你写下的文字不只是记录，工具调用以 @{工具|{参数}} 的形式嵌入其中——内容与执行合一，一行文字就是一个真实的行动。
▎工作流即文档
流程不画在画布上，而是写在文字里：扫描器像蛇一样吃掉标记、让文档在执行中生长，计划、执行、记录、产物是同一份文档的不同时刻。
▎文档即画布
它既是人思考的载体，也是 LLM 工作的现场，更是多个 AI 共享的信息空间——人类编辑它，模型驱动它，Agent 协作它，一切协作都发生在这份看得见、改得动、留得住的文档上。
以上，是 SnakeEats 的理念。
· 当前项目是验证性的，正处于项目初期，未来将根据情况改造，但我希望 SnakeEats 的理念能传播出去，能让你获得启发，期待体验者、合作者、生态开发者。
· 工具直接以本机进程执行，没有沙箱——个人用很爽，企业采纳有门槛，但理念绝对有价值。
· 前端是 textarea 级编辑器，和 VS Code/Cursor 的编辑体验差距明显。
· 三套代码要一起跑，新手上手有成本，未来计划完善。
但范式本身是成立的：LLM 依赖上下文，而上下文的最佳载体是文档；工作流可以用自然语言无歧义表达，而 @{tool|{params}} 就是那个既给人看、又能被机器执行的表达形式。
关于这个项目
SnakeEats 是早期开源项目，MIT 协议，技术栈朴素（Python + Flask + 原生 JS）。它不是"又一个工作流引擎"，而是一次关于"文档即程序、人机共用一张画布"的尝试。正在寻找早期体验者和合作者。
项目地址：
GitHub：https://github.com/heyy259/SnakeEats
Gitee：https://gitee.com/heyy259/SnakeEats
如果你想看背后的技术设计——扫描循环怎么实现"贪吃蛇"、工具怎么知道"自己在文档的哪里"、为什么 append 和 insert_after 决定了工作流的灵活性，下一篇完整解剖。