为什么做这个项目
在使用 AI Agent 处理真实业务时，我发现单次对话很难完成需要多轮决策的任务。常见的痛点是：模型一次性生成的内容不可控，中间步骤无法复用，失败后只能从头再来。
我需要一个框架，让 Agent 的每一步都可以被定义、观测和替换。目标使用者是像我一样在构建 AI 产品的工程师，他们需要一个能把“提示词 + 工具调用 + 结果校验”组合成稳定流程的底座。
我是怎么做的
核心设计是把 Agent 执行抽象成一条节点链：每个节点有明确的输入契约、输出契约和校验规则。节点之间通过类型化的上下文传递数据，而不是依赖自由文本拼接。
关键判断有三点：
- 节点而非函数：把每一步建模为独立节点，而不是函数调用。这样可以在运行时替换、跳过或重试单个节点，而不影响整条链。
- 校验前置：每个节点的输出在进入下一节点前必须通过 Zod Schema 校验。不符合契约的数据立即中断，避免错误向后传播。
- 可观测性优先：每个节点的输入、输出、耗时和 token 消耗都记录到结构化日志，方便事后复盘和优化。
技术栈选了 TypeScript 做类型安全的契约定义，运行时基于异步迭代器实现节点间流转，避免引入重型调度框架。
结果与收获
框架在一个内容审核场景跑了三个月，处理了约 12 万条任务。相比之前的单次对话方案，任务成功率从 71% 提升到 89%，主要收益来自失败节点的定向重试。
限制是：当前只支持线性与简单分支流程，复杂的并行编排还需要手动管理。实践上的认识是——Agent 的可靠性不来自更强的模型，而来自更清晰契约和更细粒度的重试。把不确定性限制在单个节点内，整条链才可能稳定。