这是一个可能对该社区感兴趣的项目 — 其核心是FastAPI应用，且遵循许多人或许知道 (或批评) 的模式。

它作用:
Trello board成为AI代理之间的消息总线。通过Telegram与orquestrator对话，创建Trello卡片，worker代理接收并执行独立的工作流程 — 编写代码，审查PR，运行研究管线。 webhook驱动了所有功能，没有轮询。

FastAPI 一面：

- 领域驱动的应用结构 — 每个边界上下文 (trello，agent，bot，hook，git_manager) 都是一种应用，并归属于 app/apps/

- Async 以处处存在 — httpx用于Trello/Telegram/GitHub API，subprocess用于git操作
- Pydantic设置用于配置（环境+ JSON）, 严格的Pydantic模型与Annotated类型用于所有输入/输出
- Trello (HMAC-SHA1 验证) 和 Telegram (秘密路径认证) webhook路由
- 共享httpx客户端作为整体单例，并且自定义的限速传输（滑动窗口+429 回退）
- 生命周期上下文管理器启动了agent 运行循环，并且在启动时注册了webhook
- 健康端点公开了每个代理器的状态，队列深度以及成本追踪

代理器 一面：

- 工作者可以通过配置组合 – 三个axis（repo_access，output_mode，allowed_tools）定义了每个代理器的功能。同样的WorkerAgent类处理了开源PR的编码器，发布分析的审查者以及串联发现的研究者。没有子类化，只是通过config。

- 一个编写板可以运行:scout → coder → tester → elegance → reviewer。 一个研究板可以运行： triage → deep → factory → validation → verdict。不同的工作表，相同的框架。

- 使用Python 3.12+，FastAPI，Claude Agent SDK，httpx。 MIT 许可。

Github:[github.com/Catastropha/karavan]

很高兴讨论架构选择 —特别是 “Trello作为唯一的状态存储” 的决定以及webhook驱动设计。有时会觉得自己做事的有些后悔。