ai-team作战架构揭秘：六阶段流水线中代码与LLM的分工逻辑
上篇分享了我从纯开发转向统筹角色的心路历程。这篇直接展示作战全景图—ai-team这条接单生产线划分为6个环节,明确哪些由代码掌控,哪些交给LLM消耗token,以及背后的设计逻辑。
先梳理一下术语。OPC超级个体(One-Person Company)是整套方案的目标用户—一个人加上一支数字团队承接外包项目。ai-team是我为这套编排系统命名的项目名称。下图呈现了它当前的架构框架,目前仍处于dry-run阶段,尚未实际接单。
六个S阶段之间穿插两个飞书审批节点。第一道关卡控制报价,第二道关卡控制交付。这两处是整套系统中唯一会主动通知我的环节—其他时间ai-team自主运行,我只需刷手机即可。
理论上如此。
分享一个反直觉的现象:
六个阶段中,真正完全交给LLM的只有S2和S5;S6是LLM与代码各占一半;S1/S3/S4以及两个gate全部由代码和配置完成。
『S1 INTAKE · 代码』通过Confluence API拉取页面,解析模板字段(标题/需求/截止时间/预算上限),统一转换为intake.json。这一步LLM不消耗任何token。
『S2 CLASSIFY · LLM』将intake.json输入一个分类agent,输出{type, difficulty, est_hours, risk_flags}。这步做的是软性分类,代码无法胜任。
『S3 QUOTE · 代码』根据S2输出的type/difficulty/est_hours套用报价公式,计算出报价区间和工期。这里坚决不让LLM参与金额计算,公式固定,我可以调整参数,出错能通过git diff追溯。
『S4 DISPATCH · 代码』启动一个Claude Code的Agent(isolation='worktree')子agent,将任务包投入其中,注册到任务表。纯属调度,与LLM无关。
『S5 EXECUTE · LLM』子agent执行任务,这是token消耗最密集的环节。具体如何编排留给后续的deep dive篇展开,这里暂不深入。
『S6 DELIVER · 对半开』LLM执行QC checklist(字数/完整度/客户字段对齐),代码负责打包/归档/提交。
为何如此划分,一句话概括:
涉及「花费多少/走哪条路径/是否终止」的决策,一律由代码处理;涉及「分类/起草/评分/摘要」的,一律交给LLM。
让LLM掌控金钱和路由,我无法安心。LLM负责起草、我来审核,我心里有把握。
我研究过两类同行的方案。
一类是n8n/Zapier那种全节点拖拽模式。每一步都是固定的,LLM只是其中一个node,想加一句「难度>8就走另一条管线」得拖五个分支,改一次头疼一周。
另一类是AutoGen/CrewAI那种「丢给一群agent自行协商」的模式。看demo很炫酷,真接活儿我不敢。我不知道它何时会自己决定「再调几次更贵的模型不就解决了」,收到账单才欲哭无泪。
ai-team走中间路线:
骨架是代码状态机(六个S加两个gate),关节是LLM子agent。骨架确保资金不会失控、路径不会混乱、终止条件可枚举;关节负责分类不死板、草稿可用、QC能挑出离谱问题。
这套架构的盈亏平衡点在哪?我自己算过一笔粗账(具体数字脱敏):一单从S1跑到S6的LLM成本主要集中在S5,S2/S6那点classifier+QC费用基本可忽略。所以单子越简单(S5越短),这套编排的额外开销越不划算—简单单子我手写两小时就能交付,ai-team要经历INTAKE→CLASSIFY→QUOTE→等gate→DISPATCH→EXECUTE→QC→等gate,一圈下来overhead比省下的时间还多。
所以我现在dry-run阶段反复验证的,不是「能不能跑通」,而是「什么类型的单子值得走这条管线」。初步结论是:标准化程度高、可拆分、QC标准明确的单子适合(某类内容改写、某类报告生成);非标+客户来回沟通多的单子,这套编排适得其反,不如手写。
报价gate和交付gate,不是「保险起见加一下」,是红线。
报价gate:LLM classifier偶尔会把难度估偏—估低了我亏,估高了客户跑,报价公式套上去结果就跑偏。所以S3算完报价,必须我在飞书点approve才会进入S4 dispatch。我现在的default习惯是:S2难度估到某个阈值以上的单子,gate卡上时我会真的去看一眼S2的raw输出,而不是闭眼approve。
交付gate:不管S6的LLM QC给了多高分,在发给客户之前必须我点approve。
对客户披露「AI辅助」是一回事,把没人审过的东西直接发出去是另一回事—后者出问题就是ToS风险+信任崩塌。
这两个gate其实就是我这「指挥官」身份的具象化体现—我不写代码,但我决定钱怎么报、东西要不要发。中间所有体力活是数字员工干的。
S2 classifier现在是单prompt一发了之,输出{type, difficulty, est_hours, risk_flags}。我纠结的是:difficulty和est_hours该不该解耦成两个agent投票,还是继续单agent一把梭。单agent简单,但难度估准≠工期估准,这两者相关性没我想象中强。
下篇大概率就从S2开始拆解—不是因为它最复杂,而因为它是整条管线里唯一一个「LLM输出直接决定钱」的节点,错了代价最高。
本文内容由 AI 辅助生成
[《AI 数字员工 · OPC 超级体造车记》第 2 篇 · 上篇:《我为什么开 ai-team: 从码农转指挥官的系列开端》]