企业官网建设流程全解析

Bernstein是一个开源的 AI Agent 治理与编排框架（Apache-2.0）：你只需写一份 YAML 文件，声明目标、阶段、依赖和预算，它就能自动把任务拆给多个 AI 编码 Agent 并行执行，并生成可验证、可回放的运行记录。本教程带你从零看懂 Bernstein 的两种编排原语——Plan（阶段式计划）与Workflow（节点式管线），用最少的心智成本编排出复杂的 AI Agent 工作流。

为什么用一份 YAML 编排 AI Agent 工作流？

让多个 AI Agent 协作开发时，你通常会遇到三个痛点：

1. 任务拆解靠拍脑袋—— 谁来写模型、谁来写测试、谁先谁后，全靠口头沟通；
2. 并行冲突不可控—— 两个 Agent 改同一批文件，互相覆盖；
3. 结果无法复核—— 运行黑盒，出问题只能重跑，说不清哪一步错在哪。

Bernstein 的思路是Policy as Code：把"谁可以做什么、什么需要审批、什么必须留痕"都写进声明式 YAML。它的调度器是纯 Python 的确定性代码——协调环路里没有 LLM，所以同一份 Plan 重放就能得到字节一致的任务图，天然可审计、可回放。

Bernstein Plan：把目标拆成"阶段 + 步骤"

Plan 是一份描述目标执行图的声明式 YAML，数据模型非常简单：

Plan → Stage（阶段）→ Step（步骤）→ Task（任务）

• 阶段（stage）默认串行执行，用depends_on声明跨阶段依赖；
• 同阶段内的步骤（step）并行执行，每个步骤会被物化为一个Task，派发给一个 Agent；
• 每个步骤可以指定role（如backend、qa、security、docs）、scope（规模）、complexity（复杂度）和files（文件所有权，用于冲突检测，防止并行 Agent 互相覆盖）。

一个最小可用的 Plan 文件

以官方文档中的示例为蓝本，一个带限流功能的后端特性 Plan 长这样（节选）：

name: rate-limit-api description: Add Redis-backed rate limiting to the public API. budget: "$5" stages: - name: design steps: - title: "Pick rate-limit algorithm" role: architect complexity: medium scope: small - name: implement depends_on: [design] steps: - title: "Add RateLimiter middleware" role: backend complexity: high files: - src/api/middleware/rate_limiter.py completion_signals: - type: file_contains path: src/api/middleware/rate_limiter.py contains: "class RateLimiter" - title: "Write rate-limiter unit tests" role: qa completion_signals: - type: test_passes command: pytest tests/test_rate_limiter.py -q - name: verify depends_on: [implement] steps: - title: "Run full test suite" role: qa

两个值得注意的细节：

• completion_signals是机器可校验的完成条件（路径存在、测试通过、文件包含某字符串、LLM 评审等），由框架的 janitor 自动核验，而不是让 Agent 自己"说完成了"；
• budget直接写进文件，为整次运行设花费上限。

Plan 关键字段速查

完整 schema 与加载行为见官方文档 docs/architecture/plans.md，加载器实现位于 plan_loader.py。

校验并运行你的 Plan：两条命令

写好 Plan 后，先校验再执行，是 Bernstein 推荐的 CI 姿势：

# 1. 校验：schema、重复标题、依赖引用、环检测 bernstein plan validate plans/rate-limit-api.yaml # 2. 执行：每个 step 变成一个 Task，由调度器并行派发 bernstein run --from-plan plans/rate-limit-api.yaml

校验输出会告诉你阶段数、任务数和最大并行宽度；退出码0表示通过，1表示有错误——在 CI 里直接按退出码分支即可。

不想手写 YAML？可以让 LLM 帮你起草一份（默认不会自动执行，需人工审校后再 validate + run）：

bernstein plan generate "Add Redis-backed rate limiting to all API endpoints"

Bernstein Workflow：带循环与命令节点的轻量管线

Plan 适合"阶段式"的工程交付；如果你的场景是一条固定的可重复管线（研究 → 实现 → 跑测试 → 开 PR），用 Workflow manifest 更轻：它是agent与command两种节点组成的 DAG，支持loop循环重试，{goal}占位符在运行时注入。

官方内置的idea-to-pr模板就是一个经典例子：

name: idea-to-pr nodes: - id: research agent: manager prompt: "Research the goal: {goal}" - id: plan depends_on: [research] agent: architect prompt: "Turn the research brief into a concrete plan for: {goal}" - id: implement depends_on: [plan] agent: backend prompt: "Carry out the plan for: {goal}" - id: tests depends_on: [implement] command: "pytest -x -q" - id: open-pr depends_on: [tests] command: "git push -u origin HEAD && gh pr create --fill"

运行与断点续跑只需两条命令：

bernstein workflow run idea-to-pr -g "Add JWT auth" # 输出 run_id bernstein workflow resume <run_id> # 中断后从首个未完成节点续跑

refactor-with-tests模板还演示了循环直到测试变绿的写法：loop: {until: "pytest -x -q", max_iterations: 5}，节点会反复触发直到谓词退出码为 0。

Workflow 的完整命令表、节点字段说明见 docs/operations/workflows.md，内置模板位于 templates/workflows/。

Plan 还是 Workflow？一张表做选择

官方建议：线性/阶段式工作用 Plan，需要条件边或重试循环才用 Workflow。

从官方模板起步：24 份 Plan + 6 套 Workflow 示例

不想从零写？仓库自带大量可直接改用的示例：

• 24 份完整 Plan 示例：examples/plans/ —— CI/CD 流水线（ci-cd-pipeline.yaml）、认证系统重构（auth-system.yaml）、Cobol 现代化、数据库迁移等；
• 5 份 Plan 模板：templates/plans/，例如生产级 REST API 模板 rest-api.yaml，可先用bernstein templates use rest-api plans/my-api.yaml生成到本地再修改；
• Workflow 模板：idea-to-pr.yaml、refactor-with-tests.yaml、hot-fix、doc-update 等。

每个示例文件的头部注释都写明了运行方式，照抄即可。

常见问题速答

问：必须安装哪些 Agent 才能跑？至少一个 CLI 编码 Agent（Claude Code、Codex CLI、Gemini CLI 等 50+ 适配器之一）并登录即可，bernstein doctor可检查适配器状态。

问：Plan 里能限制花多少钱吗？能。顶层budget: "$10"即整次运行的花费上限；命令行--budget优先。

问：重跑同一个 Plan 会重复创建任务吗？任务按标题去重，标题不变则视为同一任务；幂等重放推荐用bernstein replay。

问：运行记录存在哪里，能离线验证吗？状态落盘在.sdd/工作区（回放日志、审计链、成本台账），运行可事后离线验证——这正是 Bernstein 作为"治理层"的核心价值。

小结

• Plan：stages 串行、steps 并行的两层结构，配合completion_signals与files冲突检测，适合工程化交付；
• Workflow：agent/command 节点 DAG + 循环，适合可重复的固定管线；
• 两条黄金命令：bernstein plan validate先校验，bernstein run --from-plan/bernstein workflow run再执行；
• 所有运行都产出可验证、可回放的记录，非确定性会以哈希不匹配的形式精确暴露到出错的步骤。

更多进阶阅读：plans 架构文档、workflow 操作手册、per-step 路由指南、任务 DAG 说明。