Babysitter：通过确定性状态机实现无幻觉的代理工作流编排

AI 编程助手的能力边界正在被重新定义。当 Claude Code、Codex 等工具能够自主完成数百行代码的编写时，一个更深层的问题浮出水面：如何让这些 "智能代理" 的行为变得可预测、可审计、可回滚？a5c-ai 开源的 Babysitter 框架给出了一个工程化的答案 —— 通过确定性工作流编排，将代理的自主行为严格约束在预定义的代码化流程之内。

代理自主性的悖论

当前 AI 编程工具的核心痛点并非能力不足，而是行为不可控。同一个提示词在不同会话中可能产生截然不同的实现路径；代理在长时间对话后容易偏离原始需求；"差不多完成了" 的状态往往意味着还有大量边界情况未处理。更严重的是，代理倾向于自我认证完成度 —— 当 LLM 宣布 "任务已完成" 时，往往缺乏外部验证机制来确认这一声明的真实性。

这种不确定性在团队协作场景中会被放大。当多个开发者使用 AI 工具并行工作时，缺乏统一的质量标准和执行轨迹记录，使得代码审查变得困难，问题追溯几乎不可能。Babysitter 的设计哲学正是针对这一痛点：将代理从 "自由执行者" 转变为 "流程参与者"，通过代码定义的工作流来约束其行为空间。

Process-as-Code：流程即权威

Babysitter 的核心架构建立在 "流程即代码"（Process-as-Code）的理念之上。与传统配置驱动的工作流引擎不同，Babysitter 要求开发者用 JavaScript/TypeScript 编写完整的流程定义，明确每个步骤的准入条件、执行逻辑和退出标准。

async function process(inputs, ctx) {
  // 阶段一：规划
  await ctx.task(plan, { ... });
  
  // 强制停止点：人工审批
  await ctx.breakpoint({
    question: 'Approve plan?'
  });
  
  // 阶段二：实现
  await ctx.task(implement, { ... });
  
  // 质量门：代码验证
  const score = await ctx.task(verify);
  if (score < 80) {
    await ctx.task(refine, { ... });
  }
}

这种代码化流程的关键在于强制停止机制（Mandatory Stop）。代理在完成每个任务后必须停止执行，由流程代码决定下一步动作。这与传统 AI 对话的连续执行模式形成鲜明对比 —— 在 Babysitter 的约束下，代理无法 "擅自继续" 或 "即兴发挥"，其行为被严格限制在流程代码所允许的范围内。

质量门与收敛循环

Babysitter 引入了软件工程中成熟的质量门（Quality Gates）概念来替代代理的自我认证。开发者可以定义具体的完成标准：测试通过率、代码覆盖率、Lint 规则合规性、类型检查状态等。代理必须在满足所有这些条件后才能进入下一阶段。

这种机制创造了所谓的收敛循环（Convergent Loop）：当质量门检测失败时，流程会自动触发修复任务，代理需要迭代改进直到满足所有标准。这与传统 AI 编程中 "一次性生成" 的模式形成对比 ——Babysitter 确保工作流在达到预定义的质量阈值之前不会终止，从根本上杜绝了 "差不多就行" 的幻觉。

框架内置的 2000+ 流程库覆盖了从 TDD 开发、代码重构到安全审计、合规检查的多种场景。这些可执行蓝图将社区验证的最佳实践编码为可复用的流程模板，使得团队可以快速建立标准化的 AI 辅助开发流程。

事件溯源与可恢复性

Babysitter 采用事件溯源（Event Sourcing）模式记录每一次任务执行、质量门检查和人工决策。所有状态变更都被写入 .a5c/runs/ 目录下的不可变日志，形成完整的执行轨迹。

这一设计带来了几个工程优势：

• 可恢复性：当会话因上下文限制或网络问题中断时，可以从任意检查点恢复执行，无需重新开始
• 可审计性：完整的决策链为合规审查提供了技术基础
• 可重现性：相同的输入和流程定义保证产生一致的执行路径

对于长时间运行的复杂任务，这一机制尤为重要。开发者不再需要担心 "第 47 步时代理忘记了原始需求" 这类上下文漂移问题 —— 流程状态被持久化到日志中，代理在恢复时可以从精确的上下文继续执行。

多 Harness 支持与 CI/CD 集成

Babysitter 采用 Harness 抽象层来支持多种 AI 编程工具。目前官方支持 Claude Code（推荐）、Codex CLI、Cursor、Gemini CLI、GitHub Copilot 等主流工具，并提供实验性插件支持。

特别值得关注的是 Internal Harness 模式。这一模式允许 Babysitter 在没有外部 AI 代理的情况下运行流程，完全基于 SDK 内置的执行引擎。这使得 Babysitter 可以直接集成到 CI/CD 管道中：

babysitter harness:call \
  --harness internal \
  --process .a5c/processes/lint-and-test.js#process \
  --workspace . \
  --no-interactive \
  --json

在 CI/CD 场景中，Internal Harness 可以调用已安装的其他 Harness 来执行需要 AI 能力的子任务，实现 "无头编排"（Headless Orchestration）与 "智能代理" 的混合工作流。

Token 压缩与上下文优化

针对长流程执行中的上下文窗口限制问题，Babysitter 内置了四层 Token 压缩系统：

实测表明，这一系统可以在保持 99% 事实保留率的前提下，将上下文窗口使用量减少 50-67%。对于需要处理大量代码库或执行多步骤复杂任务的代理工作流，这一优化显著提升了可扩展性。

实践建议：从确定性子流程开始

将 Babysitter 引入现有开发流程时，建议从高度确定性的子任务开始。例如，将代码格式化、类型检查、单元测试等已有明确成功标准的任务封装为 Babysitter 流程，逐步建立团队对质量门机制的信任。

定义完成标准时应遵循可验证优于可描述的原则。与其说 "代码应该高质量"，不如定义 "测试覆盖率不低于 80%、Lint 零错误、类型检查通过"。这些可自动验证的指标消除了代理对 "完成度" 的主观判断空间。

对于需要人工判断的关键节点，应显式设置断点（Breakpoint）而非依赖代理自行决定何时寻求确认。Babysitter 的断点是强制性的流程元素，代理无法绕过或忽略。

结语

Babysitter 代表了 AI 辅助开发工具演进的一个重要方向：从追求代理的 "更聪明" 转向追求工作流的 "更可控"。通过将流程定义代码化、执行轨迹事件化、完成标准量化，这一框架为团队提供了一种在享受 AI 生产力的同时保持工程纪律的方法。

在确定性流程与智能代理的结合点上，Babysitter 提供了一个可参考的工程范式 —— 不是用代理取代流程编排，而是将代理嵌入到受控的流程编排之中。

资料来源

• GitHub - a5c-ai/babysitter：框架官方仓库，包含完整文档和插件生态
• a5c.ai：项目官方网站，介绍核心概念和使用场景
• Camunda - Guardrails and Best Practices for Agentic Orchestration：企业级代理编排的行业最佳实践参考

ai-systems