一、背景
最近一段时间，“小龙虾”（一类 Agent 框架的俗称）非常火。
很多方案主打：
- 自动调用工具
- 多轮推理
- 自主决策执行任务
看起来像是：
一个 AI 可以自己完成复杂工作流
但实际落地之后，很多工程团队会遇到一个问题：
能跑 ≠ 好用
尤其是在工程领域（MR评审 / dump分析 / 日志分析），你很快会发现：
- 可控性不足
- 调试困难
- 成本（token）不可控
- 和本地工具链集成困难
二、“小龙虾”的核心原理
从工程角度看，这类 Agent 本质上就是一个循环：
while (任务未完成):
1. 构造 prompt
2. 调用 LLM
3. 解析输出（决定调用哪个工具）
4. 执行工具
5. 将结果加入上下文
可以抽象成：
while not done:
response = llm(prompt + context)
action = parse(response)
if action.type == "tool":
result = run_tool(action)
context.append(result)
elif action.type == "finish":
done = True
核心问题
这个模型的问题在于：
1）不确定性
LLM 决定流程
意味着：
- 不稳定
- 难复现
- 很难做精确控制
2）成本问题
每一步都在调用 AI
很多操作其实是：
- 可确定逻辑
- 可规则化
但仍然走了 LLM：
=> token 浪费
3）工程集成问题
现实工程中你会用到：
- WinDbg
- GitLab API
- 本地脚本
- 日志处理工具
而 Agent 框架更偏：
HTTP API + JSON 工具调用
对本地工具支持不友好。
三、工程实践：反向设计
基于这些问题，一个更工程化的思路是：
用代码控制流程，用 AI 做“分析器”
而不是：
让 AI 控制流程
四、目标系统
我当前的需求包括：
- MR 自动评审（规则 + AI）
- dump 自动分析（WinDbg + AI）
- 日志自动分析（预处理 + AI）
- 企业微信通知
这些任务有一个共性：
流程是确定的，AI只是其中一个环节
五、架构设计
最终设计如下：
automation/
├ scheduler
├ tools
├ ai
├ channels
└ tasks
1、Scheduler（调度层）
职责：
- 定时执行任务
- 管理任务生命周期
示例：
scheduler.add_job(mr_review.run, interval=5min)
2、Tools（工具层）
封装所有“确定性能力”：
tools/
├ gitlab
├ dump
└ log
例如：
class GitLabTool:
def get_mrs(self):
return requests.get(...)
3、AI（分析层）
只做一件事：
分析输入，输出结果
例如：
class CursorAI:
def analyze(self, text):
return run_cursor_cli(text)
4、Channels（输出层）
统一通知：
企业微信 / Webhook / 邮件
class WeCom:
def send(self, msg):
requests.post(webhook, msg)
5、Tasks（业务层）
每个任务就是一个完整流程：
任务 = orchestration（编排）
六、MR 自动评审流程
完整流程：
定时轮询 GitLab
↓
获取 MR 列表
↓
过滤已评审 MR（JSON 记录）
↓
获取 diff
↓
规则检查（本地逻辑）
↓
AI 分析（Cursor）
↓
生成结果
↓
企业微信通知
伪代码
def run():
mrs = gitlab.get_open_mrs()
for mr in mrs:
if already_reviewed(mr):
continue
diff = gitlab.get_diff(mr)
# 1. 规则检查（确定逻辑）
rule_result = check_rules(diff)
# 2. AI 分析（不确定逻辑）
ai_result = ai.analyze(diff)
# 3. 汇总结果
result = merge(rule_result, ai_result)
# 4. 通知
wecom.send(format_msg(result))
mark_reviewed(mr)
七、关键设计点
1）AI 只做“不可确定”的部分
规则 → 代码
分析 → AI
避免：
让 AI 做流程控制
2）状态最小化（JSON 即可）
当前仅记录：
{
"reviewed_mrs": [123, 124]
}
目的：
避免重复分析
不引入数据库，保持系统轻量。
3）模块解耦
Tools / AI / Channels / Tasks 完全解耦
好处：
- AI 可替换（Cursor → 其他模型）
- 通知渠道可扩展
- 任务可复用工具
4）本地工具优先
直接调用：
subprocess.run(["windbg", ...])
subprocess.run(["cursor", ...])
而不是强行抽象成 API。
八、为何不直接用Agent框架
总结一句话：
Agent 适合探索问题
工程系统需要确定性
在我的场景中：
- 流程固定
- 工具明确
- 输入输出清晰
因此：
用代码编排 + AI分析 → 更稳定、更高效
九、下一步演进
这个架构可以逐步升级：
1）增强状态管理
- JSON → SQLite
2）增加任务监控
- 执行日志
- 失败重试
3）增加 UI（可选）
当任务变多时：
任务面板 / 状态监控
4）AI能力增强
- 多模型融合
- Prompt 模板管理
- 分析结果评分体系
十、总结
相比“让 AI 控制一切”的 Agent 模式，一个更适合工程落地的方案是：
代码控制流程
AI 提供智能
这样可以做到：
- 可控
- 可调试
- 成本可控
- 易扩展
本质上，这是一个：
AI + 工程化 的融合问题
而不是单纯的“用 AI 替代一切”。
