Workflow vs Agent：用 7 维度框架定位你的项目

先纠正一个前提，再回答担忧——这个担忧的方向反了，但背后有个真问题。

前提纠正：MoneyPrinterTurbo 不是 Agent 项目，这 7 个维度大多不适用

用这 7 维度审视 MPT，结论恰恰是"它几乎一个都不占"——这不是 PR 的缺陷，而是项目性质使然：

维度	MPT 的真实情况
1. 任务规划	无 LLM 规划层。LLM 只做内容生成（脚本/关键词），执行流是 `task.py` 写死的 5 阶段顺序管线，失败策略是跳过/中止，无动态重规划
2. 多 Agent	无。是 workflow 不是 agent——Orchestrator+Worker 的类比物存在（task.py 编排 + services 各司其职），但通信是函数调用，无协议、无状态共享
3. 上下文管理	不存在。所有 LLM 调用都是单轮无状态的（一次 prompt 一次响应），没有对话历史，也就没有截断/压缩问题
4. Human-in-the-loop	仅参数层（WebUI 配置确认），无运行中干预、无 checkpoint 恢复（state.py 存的是进度状态，不是决策断点）
5. 评估框架	pytest 878 个测试是代码正确性测试，不是 agent 评估（无 trajectory、无工具调用质量追踪）
6. Tool 检索	无 tool use。provider 是用户静态选择（video_source 参数），不是模型动态路由
7. Streaming	LLM 输出不流式；任务进度靠轮询 state（唯一有真实讨论空间的一项）

面试官如果懂行，不会从 MPT 的 PR 里期待 agent 架构研究——他们期待的是生产工程能力（计费安全、失败语义、降级设计、开源协作），而你的 PR 恰好满格。拿着 7 维度框架硬套 MPT 做出"深度分析"，懂行的面试官反而会怀疑你的判断力：把 workflow 当 agent 分析，是概念混淆。

真问题：你的 agent 深度证据链目前是空的

停止 PR 投递后，你的叙事资产是：MPT 双 PR（生产工程线）+ 即将做的 LiveTalking（实时音视频线）——两条都不是 agent 架构线。如果目标 JD 是"AI Agent 工程师"，这才是缺口。三个补法，按性价比排序：

1. 把 7 维度框架用在正确的对象上

分析 MPT 时作为"workflow vs agent 光谱"的定位工具：一句话版本是"MPT 位于光谱最左端（固定管线），LLM 只是内容生成器；若引入规划层，最自然的位置是 task.py 编排器之前（素材策略规划：根据主题决定检索还是生成、按 BGM 节奏规划片段时长），改造成本约一个新 service + VideoParams 扩展，且不破坏现有管线"。

能说清"为什么这里不需要 agent"比硬说"这里有 agent"更显研究深度——知道何时不用 agent，是 agent 工程师的第一课。

2. LiveTalking 才是 7 维度的主战场

实时数字人天然覆盖维度 3（流式上下文）、7（streaming 与中间状态）、4（打断 = HITL 变体）、1（对话轮次内的即时决策）。做之前用这 7 维度做架构分析（正是你贴的这个模板的用途），PR 叙事自然长出 agent 肌肉。

3. 如果 agent 线必须马上有东西

比第三个 PR 更快的是一篇分析文档——挑一个真 agent 项目（比如 OpenClaw/LiveTalking）做 7 维度缺陷分析发成博客/issue。分析能力不需要 PR 来证明，但需要一个载体。

面试话术（如果被问"你的 PR 没体现 agent 研究"）

"MPT 本来就不是 agent——它是固定管线的 workflow，LLM 在里面只是内容生成器，我不认为应该为了简历好看往 workflow 里塞 agent。我的这个 PR 体现的是另一层：生产环境对外部付费 API 的失败语义建模。agent 架构的能力我用两个方式证明：一是能精确说清 MPT 在 workflow→agent 光谱上的位置、以及在哪里引入规划层是值得的哪里是过度设计；二是 LiveTalking 的实时链路实践（流式、状态可见性、打断）——那是 agent 维度真正存在的地方。"