案例分析一：Coding Agent 从本地脚本迁移成 Web 产品

这个案例最适合直接看对比图。左边是错误做法：Web 请求直接去调本地脚本，能跑，但会带来超时、强耦合、状态混乱和难扩展的问题；右边则是正确迁移方式：前端调用 Flask Route，再到 AgentService、AgentEngine，最后把任务结果通过 Run 状态返回给前端。

图里有一个特别值得注意的点：迁移的本质不是把原脚本推倒重写，而是把原来那套执行逻辑包进一个更完整的服务链路里。这样做以后，前端可以轮询任务状态，服务端可以统一管理任务、用户和权限，整套产品就开始具备“真正可上线”的样子了。

场景背景

最初只有：

result = agent.run(
    "修复这个项目"
)

开发者自己在终端使用。

现在要做一个网页，让用户：

选择项目
输入任务
点击运行
查看结果

错误做法

为了快，所有逻辑写进：

@app.post("/chat")
def chat():
    ...

里面同时：

创建 Provider
加载 Tool
读取 Session
拼 Context
运行 Main Loop
更新 Memory
写日志

几周后 Route 变成数百行。

任何一个新入口都得复制这套逻辑。

正确迁移

保留原有：

AgentEngine

新增：

AgentService

再增加：

Flask API

调用链：

Browser
 ↓
POST /api/v1/chat
 ↓
Flask Route
 ↓
AgentService
 ↓
AgentEngine
 ↓
Context / Tool / Memory

结果

后面接飞书时，不需要复制 Engine。

只需要增加：

Feishu Adapter

最终：

Web ------┐
Feishu ---┼→ AgentService → AgentEngine
CLI ------┘

迁移复盘

真正被服务化的是，Agent 的访问方式。

而不是重新实现一个“Web 版 Agent”。

只要这一点把握住，后面系统会清晰很多。