第4部分：Python + Flask 服务化 为什么 Agent 不能永远运行在 Python 脚本里？

到上一部分结束，我们已经把 Agent Harness 最核心的一大块能力搭出来了。

现在这个 Agent 已经不再只是一个最小 while True Demo，而是已经拥有：

Main Loop
Agent State
LLM Provider
Tool Registry
Tool Schema
基础 Tool
Error Recovery
Parallel Tool Calling
ContextBuilder
Working Memory
Session
Context Window Monitor
Context Compaction
Long-term Memory

在本地，我们完全可以这样调用：

answer = agent.run(
    "分析这个项目"
)

它能读取文件、调用工具、保留状态、处理错误，并最终给出结果。

但如果准备把它真正交给别人使用，一个现实问题马上出现，谁来调用这个 agent.run()？

你自己在终端里当然可以直接运行 Python。

可浏览器不能直接进入服务器的 Python 进程执行方法，手机 App 也不能 import AgentEngine，飞书机器人更不可能直接调用你本地脚本里的函数。其他 Java、Go 或 Node.js 服务，也不应该为了使用 Agent 被迫嵌进同一个 Python 环境。

因此，从这一部分开始，我们要在保留本地入口的同时，把：

本地函数调用

升级成：

网络服务调用

架构从：

Python Script
   ↓
agent.run()

变成：

Frontend
App
飞书
其他服务
    ↓
HTTP API
    ↓
Agent Server

这就是我们正式引入 Flask 的原因。

先把适用范围说清楚：不是每个 Agent 都必须变成 Web 服务。只在本机使用、由一个开发者触发的自动化工具，CLI 往往已经足够稳。需要跨设备、跨语言、多用户或被外部平台回调时，服务边界才真正值得引入。服务化会增加部署、权限、监控和故障处理成本，我们是因为调用关系变了才增加它，不是为了让架构显得更完整。

开场引入

先看现在最熟悉的运行方式。

项目可能是：

agent_project/
├── main.py
├── agent_engine.py
├── context.py
├── session.py
├── memory.py
├── providers/
└── tools/

main.py：

from agent_engine import AgentEngine


if __name__ == "__main__":
    agent = AgentEngine()

    result = agent.run(
        "分析这个项目"
    )

    print(result)

本地执行：

python3 main.py

这个方式没有任何问题。

对于开发阶段，它甚至是最方便的形式：改完代码马上运行；看到 Tool Call 不对就打印；Provider 报错直接看 traceback；Context 拼得不对就输出 messages。我们不应该为了“看起来像生产系统”过早把一切都包装成 Web。

但当 Agent 从“我自己用的脚本”变成“别人需要调用的能力”以后，脚本的边界就不够了。

比如你做一个网页：

[ 输入任务：帮我分析这个项目 ]
              [运行]

用户点击按钮之后，浏览器必须向后端发送请求。

浏览器能做的是：

POST /api/v1/chat

它不能做：

from agent_engine import AgentEngine

再比如飞书用户发：

@Agent 帮我看看昨天收入为什么下降

其他内部系统也是一样。

告警平台可能希望：

发现异常
  ↓
调用 Agent
  ↓
自动分析

数据平台可能希望：

用户提交问题
  ↓
Agent API
  ↓
返回分析结果

所以真正的问题不是，“Flask 要不要学？”

而是，Agent 如何从某个 Python 进程里的函数，变成整个系统都能稳定访问的能力？

答案就是建立一个服务边界。

在这一层之后，我们马上会遇到新的工程问题：

请求怎么传 session_id？
一次 Agent 任务怎么标识？
任务跑 60 秒怎么办？
前端怎么实时看到进度？
服务重启以后 Session 怎么恢复？
多个用户同时调用会不会串数据？
错误怎么转换成稳定 API 返回？
客户端超时重试会不会把同一个任务创建两次？
服务开了多个 Worker 后，内存里的状态还能不能互相看见？

你会发现，Flask 不是突然插进课程的一门 Web 技术。

它是 Agent 从：

Demo

走向：

Backend Service

以后自然出现的那一层。

知识地图

我们最终希望形成：

Client
  ↓
Flask Route
  ↓
AgentService
  ↓
AgentEngine
  ↓
Harness

而不是：

Flask Route
  ↓
把 Main Loop、Tool、Memory 全写进去