以下以 Web 服务（REST API） vs AI Agent（Text2SQL 场景） 为例，从架构、代码、数据流、性能、改造工作量五个维度，逐项拆解改造细节：
✅ 1. 架构对比
| 维度 | Web 服务（REST API） | AI Agent（Text2SQL） |
|---|---|---|
| 典型结构 | 路由 → 鉴权 → 业务逻辑 → 数据库 → 响应 | 输入解析 → LLM 推理 → SQL 查询 → 结果格式化 |
| 状态管理 | 通常有会话、缓存、数据库连接 | 无状态，每轮对话独立 |
| I/O 特征 | 高并发、低延迟、短请求 | 低并发、长延迟（LLM+DB）、多阶段 |
| 计算密集度 | 低至中（JSON 处理、DB 查询） | 中至高（LLM 推理、SQL 解析） |
✅ 2. 代码级改造对比
🔹 Web 服务（以 Flask 为例）
原始代码（简化）：
@app.route("/order", methods=["POST"])
def create_order():
user_id = request.json["user_id"]
item_id = request.json["item_id"]
# 鉴权
if not auth_service.validate(user_id):
return "Unauthorized", 401
# 业务逻辑
price = db.query("SELECT price FROM items WHERE id = ?", item_id)
db.execute("INSERT INTO orders(user_id, item_id, price) VALUES (?, ?, ?)", user_id, item_id, price)
return jsonify({"status": "success"})
Dandelion DAG 改造后：
| 原函数 | 改造为 |
|---|---|
| 鉴权调用 | → AuthFunction（通信函数，调用外部 Auth API） |
| 查询价格 | → QueryPriceFunction（通信函数，调用 DB） |
| 插入订单 | → InsertOrderFunction（通信函数，调用 DB） |
| 响应封装 | → FormatResponseFunction（纯计算函数） |
DAG 结构：
输入 → AuthFunction → QueryPriceFunction → InsertOrderFunction → FormatResponseFunction → 输出
🔹 AI Agent（Text2SQL）
原始代码（简化）：
def text2sql_pipeline(prompt):
# 1. 解析输入
parsed = parse_prompt(prompt)
# 2. 调用 LLM
sql = llm_client.generate_sql(parsed)
# 3. 执行 SQL
result = db.execute(sql)
# 4. 格式化结果
return format_result(result)
Dandelion DAG 改造后：
| 原函数 | 改造为 |
|---|---|
| 解析输入 | → ParsePromptFunction（纯计算函数） |
| LLM 调用 | → LLMCallFunction（通信函数，调用 OpenAI API） |
| SQL 执行 | → SQLQueryFunction（通信函数，调用 DB） |
| 结果格式化 | → FormatResultFunction（纯计算函数） |
DAG 结构：
输入 → ParsePromptFunction → LLMCallFunction → SQLQueryFunction → FormatResultFunction → 输出
✅ 3. 数据流与调度差异
| 维度 | Web 服务 | AI Agent |
|---|---|---|
| 输入数据量 | 小（几 KB JSON） | 中（用户 prompt + schema） |
| 输出数据量 | 小（JSON） | 中（LLM 输出 + DB 结果） |
| 阶段间数据传递 | 简单（ID、价格） | 复杂（SQL 字符串、结果集） |
| 并发需求 | 高（1000+ RPS） | 低（<10 RPS） |
| 冷启动容忍度 | 低（用户交互） | 中（后台任务） |
✅ 4. 性能与资源影响
| 维度 | Web 服务改造后 | AI Agent改造后 |
|---|---|---|
| 冷启动延迟 | <1ms（纯计算） | <1ms（纯计算）+ LLM延迟（外部） |
| 内存占用 | 极低（按需分配） | 极低（按需分配） |
| CPU利用率 | 高（短任务密集） | 低（长等待 I/O） |
| 弹性扩展 | 秒级扩缩容 | 无需频繁扩缩容 |
✅ 5. 改造工作量对比（以千行代码为例）
| 任务 | Web 服务 | AI Agent |
|---|---|---|
| 代码拆分 | 需重写路由层、鉴权层、DB 层为独立函数 | 较自然，逻辑已分阶段 |
| 通信函数封装 | 需封装 Auth API、DB 查询为 HTTP 调用 | 需封装 LLM API、DB 查询 |
| 测试复杂度 | 高（需模拟鉴权、DB 状态） | 中（LLM 可 mock，DB 可 mock） |
| 开发人力 | 2-3 人日（熟练者） | 0.5-1 人日（学生案例） |
✅ 总结建议表
| 场景 | 是否推荐改造 | 主要挑战 | 建议优先级 |
|---|---|---|---|
| Web 服务 | ⚠️ 谨慎推荐 | 路由/会话/状态管理复杂 | 低优先级，除非无状态微服务 |
| AI Agent | ✅ 强烈推荐 | 逻辑天然 DAG，改造简单 | 高优先级，适合首批试点 |
评论