代理的事件溯源：AI 系统的声明式组装

声明式智能体组装：事件溯源如何解决可变状态问题

基于 LLM 的现代多智能体系统面临一个根本挑战：通过可变状态管理状态会导致不稳定性和调试难题。解决方案来自一个意想不到的来源——数据工程实践。新框架 zymi 应用了事件溯源和声明式描述原则，这些原则在 dbt 中很常见，用于构建可靠的面向智能体的系统。

声明式方法取代命令式代码

传统框架如 LangGraph 需要详细说明如何通过可变状态处理数据。这会引发几个关键问题：

• 状态变成一个隐藏依赖的混乱堆积
• 每次变更都需要手动同步
• 调试变成在打印日志中苦苦追寻的苦差事

zymi 彻底颠覆了这一范式：你只需使用 YAML 配置描述需要做什么，引擎就会自动处理执行。项目结构类似于 dbt 项目：

zymi-research/
├── agents/
│  ├── researcher.yml
│  └── writer.yml
├── pipelines/
│  └── research.yml
├── tools/
└── project.yml

每个智能体都通过声明式清单定义。例如，researcher 智能体：

name: researcher
description: "Research agent — searches the web, scrapes pages, and stores findings in memory"
model: ${default_model}
system_prompt: |
  You are a thorough research assistant. Your job is to find accurate,
  up-to-date information on the given topic.

tools:
  - web_search
  - web_scrape
  - write_memory
max_iterations: 15

工具也采用声明式描述。通过 Tavily API 实现的 web_search：

name: web_search
description: "Search the web for information on a given query"
parameters:
  type: object
  properties:
    query:
      type: string
      description: "Search query"
  required: [query]

implementation:
  kind: http
  method: POST
  url: "https://api.tavily.com/search"
  headers:
    Authorization: "Bearer ${env.TAVILY_API_KEY}"
  body_template: '{"query": "${args.query}", "max_results": 5}'

管道将智能体串联成带有依赖的步骤：

name: research
steps:
  - id: search_web
    agent: researcher
    task: "Search the web for information about: ${inputs.topic}"

  - id: analyze
    agent: researcher
    task: "Analyze findings and store structured summary"
    depends_on: [search_web]

  - id: write_report
    agent: writer
    task: "Write report to ./output/report.md"
    depends_on: [analyze]

通过 CLI 运行管道：

zymi run research -i topic="Event sourcing in AI"

事件溯源：从不可变事件到可重现性

zymi 与 LangGraph 的关键区别在于摒弃可变状态，转而采用事件溯源架构。所有交互都记录为加密验证的不可变事件链。每个事件包含：

• 前一事件的哈希（确保链完整性）
• 操作数据
• 时间戳
• 事件源

这种模型带来三大关键优势：

• 完全可追溯——任何结果都可以从事件链中重建
• 内置审计追踪——所有变更轻松记录
• 操作安全——监视器在执行前评估意图

以下是执行日志的一个片段：

#4    10:50:52.806 intention_emitted source=orchestrator
  call_custom_tool data={"type":"CallCustomTool","data":{"tool_name":"web_search"}}
#5    10:50:52.806 intention_evaluated source=orchestrator
  call_custom_tool -> approved
#49   11:20:15.321 intention_emitted source=orchestrator
  write_file data={"path":"output/report.md"}
#50   11:20:15.322 intention_evaluated source=orchestrator
  write_file -> requires_approval

这展示了系统如何先发出执行操作的意图（intention_emitted），然后监视器决定是否批准（intention_evaluated）。在文件写入尝试时，监视器要求批准——这是直接状态变更无法实现的防护措施。

对开发者和 LLM 的益处

声明式方法在生成式 AI 时代带来实际收益：

• 降低 LLM 复杂度——YAML 配置比命令式代码更容易生成
• 严格验证模式——JSON Schema 防止配置错误
• 并行执行——引擎自动识别独立步骤
• 可重现性——任何运行都可以从事件日志重放

实验显示，LLM 生成的 zymi 管道比等效 LangGraph 代码少需 30-40% 的迭代次数。这源于：

• 无需手动状态管理
• 组件间清晰的责任边界
• 静态配置验证

关键要点

• 声明式优于命令式——描述做什么而非怎么做，减轻认知负担
• 事件溯源作为基础——不可变事件确保可重现性和安全性
• 与 LLM 开发的集成——结构化配置更容易让 AI 生成和优化
• 加密完整性——哈希链保证执行历史真实性
• 意图监控——专用层审查操作以阻挡意外行为

zymi 框架展示了数据工程概念如何应对面向智能体编程的系统性挑战。从可变状态转向事件溯源架构不仅简化了开发——还开启了控制和分析 AI 智能体行为的全新可能。对于技术专家而言，这从脆弱系统转向可靠、可追溯的解决方案，每一步都有可验证证明和可重现性。

— Editorial Team