一个多智能体协作的代码审查流程，从立项到跑通，传统框架要多少行Python？作者实测：节点定义、边连接、状态模式、类封装——还没开始写业务逻辑，胶水代码已经铺了满地。
他算了笔账：每次想实现"Agent A写完代码交给Agent B审查，不通过就打回重写"这种需求，80%精力耗在框架搭建，20%才是正经事。这感觉像什么呢？就像你想煮碗面，得先从和面机的设计图纸开始画起。
于是他开始造轮子，但造的是一辆没有轮子的车。
从"写代码"退到"写配置"
新项目叫aqm，开源，MIT协议。核心就一句话：用YAML定义整个AI流水线，CLI直接跑，不碰.py文件。
作者的原话是：「我想直接说，Agent A交给Agent B，质量检查失败就返回Agent A，完全不用碰Python文件。」
这背后的判断很产品经理：当AI智能体协作成为常态，"编排"本身应该从编程问题降级为配置问题。YAML在这里不是偷懒，是刻意选择的接口层——它强制你把流程结构化，同时天然具备可移植性。一个文件丢给同事，对方环境配好CLI就能跑，版本控制也比代码仓库清爽得多。
技术实现上，aqm做了几件事来兑现这个承诺。
多模型混编与成本剪刀差
Multi-LLM Native是aqm的第一个差异化设计。同一条流水线里，Claude写代码、Gemini做安全审查、本地模型跑轻量校验——这种" horses for courses"（量才录用）的架构，在Python框架里不是不能做，但配置复杂度会指数级上升。
YAML的扁平结构让这种混编变得直白：每个agent节点标注runtime，handoffs字段指明流向，没有继承链，没有状态机嵌套。
更狠的是Token Optimization。作者内置了5种上下文策略，实测节省55%-85%的token成本。原理不复杂：只给agent看它必须看的东西，而不是把整个对话历史打包塞过去。但在传统框架里，这种优化往往需要你自己重写上下文管理器。
省下来的不只是钱，还有延迟。当agent需要处理长文档时，精简上下文意味着更快的响应和更少的超时重试。
质量门与会话节点
Quality Gates是另一个直击痛点的设计。代码审查场景里，"通过/打回"的二元判断很常见，但实现起来却要在Python里写条件分支、异常捕获、重试计数器。aqm把它收进YAML的gate字段：
type: llm
prompt: "Is this production-ready?"
max_retries: 3
LLM自己当裁判，评估输出质量。失败就重试，超次数就转人工或降级处理。这种"自指"结构——用LLM评估LLM的输出——在学术界有争议，但在工程落地层面，它解决了一个真实问题：怎么在没有人工介入的情况下，让流水线具备基本的容错能力。
Session Nodes则是另一个有趣的方向。作者举的例子是"设计会议"：多个agent来回讨论直到达成共识。这对应着现实中常见的协作模式——不是流水线式的单向传递，而是迭代式的群体决策。YAML在这里用嵌套结构表达会话边界，比用Python协程和队列清晰得多。
30秒能看懂的示例
作者给了一个最小可运行示例，完整展示开发者-审查者-部署者的三角关系：
agents:
- id: developer
runtime: claude
system_prompt: "Implement: {{ input }}"
handoffs: [{ to: reviewer }]
- id: reviewer
runtime: gemini
system_prompt: "Review for security: {{ input }}"
gate:
type: llm
prompt: "Is this production-ready?"
max_retries: 3
handoffs:
- { to: deployer, condition: on_approve }
- { to: developer, condition: on_reject }
运行命令就一行：aqm run "Create a login form with JWT"
没有main.py，没有requirements.txt里的框架依赖，没有环境变量地狱。前提是你本地已经配好了Claude或Gemini的CLI——aqm不碰API密钥管理，这个设计很聪明，既避开了安全敏感区，又降低了上手门槛。
但这也划定了边界：aqm不是全栈框架，是编排层。重度的自定义逻辑，你终究要回到Python。
开源社区的试探
项目刚放出，作者在GitHub上姿态放得很低：「找 fellow developers 来 break it, critique it, tell me what's missing」——翻译过来就是：来砸场子，越狠越好。
他抛了两个问题给潜在用户：YAML-only的工作流是否符合你的习惯？现有框架最缺的功能是什么？
第一个问题其实是产品定位的验证。YAML作为配置语言，在DevOps领域有广泛认知基础，但AI工程师群体更习惯Python的表达能力。aqm的赌注是：当智能体协作模式稳定下来，配置会取代代码成为主要交互界面——就像Kubernetes用YAML定义基础设施，Terraform用HCL定义云资源。
第二个问题则是在收集竞品缺口。多LLM混编、内置质量评估、token优化这些功能，与其说是技术创新，不如说是用户体验的缝合。作者显然调研过LangChain、LlamaIndex、AutoGen等现有方案，知道它们的臃肿之处在哪。
pip install aqm 之后，实际体验如何？社区还在早期，但已有几个值得观察的信号。
一是对"无代码"承诺的兑现程度。YAML的表达能力有天花板，复杂的状态流转、条件分支、错误恢复，写成配置是否比代码更易维护？作者用gate和handoffs做了初步抽象，但真实业务场景的复杂度很快就会测试这些原语的完备性。
二是与现有工具链的集成。aqm选择不管理API密钥，这意味着它依赖外部的CLI配置。这在个人开发场景很清爽，但在团队协作、CI/CD流水线里，密钥管理终究要有个答案。是保持克制只做编排，还是逐步侵入基础设施层，这是项目演进的关键分叉口。
三是社区贡献的方向。MIT协议下，fork和PR的门槛都很低。但YAML的扩展机制怎么设计？插件系统要不要有？这些决策会决定aqm是保持小而美，还是膨胀成另一个框架。
作者最后留下的GitHub链接和安装命令，像是一个未完成的句子的逗号。他显然知道1.0版本的功能清单不等于产品的终局形态，真正的考验是：当第一批用户真的用YAML跑起生产流程，那些没写在文档里的边缘情况，会把这个设计逼到什么地步？
有个细节很有意思：他在功能列表里把"saved my sanity"（保住我的 sanity）直接写进标题。这种个人化的表达在开源项目里不多见——它暗示了项目的起源不是技术愿景，而是具体的挫败感。这种从痛点长出来的工具，往往比从架构图长出来的更耐打磨。
但这也意味着，aqm的边界目前就是作者自己的需求边界。你的 sanity 和作者的 sanity 是否重合，得跑过几个流水线才知道。
所以最后的问题是：如果让你用YAML定义一个三智能体协作的代码审查流程，你会把"人类介入"的触发条件放在哪个节点——是审查失败时，还是部署前，还是干脆全程自动化直到出事故？
热门跟贴