生产级 AI Agent 部署实录

Agent 上线两周后，我把它关了：从玩具到系统的 6 个工程化改造

关于作者：全栈开发，后来做运维，偶尔打 CTF。现在专注让 AI Agent 在生产环境里别排乱。

本文不讲 Demo。

两周前，我给公司搭了一套 AI Agent。接企业微信、接飞书、接 GitHub，插件一共 27 个。启动那天我发了一条朋友圈：“终于解放双手了。”

两周后，我把它关了。

原因不是它不能用。相反，它太能用了。每天会发出三五份报告，但没人看。会在群里回复问题，但经常答非所问。会自动创建任务，但那些任务和当月目标没什么关系。

我意识到：Agent 不是万能的。它是一个需要被运维的系统。

本文站在生产环境视角，完整拆解一套可水平扩展、可监控、可定价的 AI Agent 架构。

一、为什么 Agent 在生产环境里这么难？

在单机演示中，Agent 看起来很简单：

配置提示词
接入工具
设置定时任务
观察输出

但一旦进入生产环境，问题会立即升级：

费用是隐性的
：你不会每天看 API 账单，等到发现时已经花了半个月工资。
幻觉是危险的
：它会生成看似正确的 SQL、看似合理的配置、看似完整的计划。等你发现，数据库已经少了一张表。
工具是臃肿的
：插件越接越多，决策链路越长，失败概率指数级上升。一个任务调用 5 个工具，完成率从 90% 跌到 30%。
状态是集中的
：所有任务、所有历史对话、所有上下文都压在一个进程里。一旦崩溃，整个系统跟着崩溃。
故障是盲目的
：你看不到 Token 消耗曲线、看不到工具响应时间、看不到错误率变化。故障发现时，通常是用户先发现的。

所以，生产级 Agent 系统的核心目标不是"做出这个功能"，而是：

可管理
：知道它在干什么、花了多少钱、调了多少次。
可控制
：不能随便发布、不能随便修改、不能随便花钱。
可观测
：故障发生时，5 分钟内能定位问题。
可水平扩展
：不能把所有任务压死在一个进程里。
故障下可恢复
：授权失败、模型抛错、工具超时，系统不能崩溃。

很多人以为 Agent 的难点是"它能不能做更多"。但真实情况是，很多系统死掉，是因为它做了很多没人用的东西。

能进入日常流程，能形成下一步动作，能让人少开新坑、多关旧坑，这些比炫技重要得多。

二、先把语义说清楚：你到底在部署什么"Agent"？

很多系统后期返工，不是因为代码写错，而是因为语义定义不清。

市面上的"AI Agent"至少有三种完全不同的定义：

模式	语义	优点	风险
按指令执行	每次用户发起对话，Agent 单次响应	简单、可控、易排查	无法处理多步任务，每次都是冷启动
按任务状态执行	维护一个持久化任务地图，可以跨多次对话推进	适合复杂项目级任务	状态管理复杂、需要持久化存储
按自主循环执行	Agent 持续运行，主动发起任务、主动报告	真正的"自动化"，无需人工触发	权限边界难控制、意外行为难预测

对于生产系统，我建议优先采用"按任务状态执行"。

即：

每个任务有独立状态机：pending → running → completed/failed
每个任务有独立上下文，不会因为前一个任务的错误影响后一个
任务可以跨次对话继续，也可以被中止和重试

这个模型有三个优势：

状态可见，不用猜它到底在干什么
失败可恢复，单个任务崩了不影响其他任务
可审计，每个任务都有完整的操作日志

三、目标架构：把模型、工具、状态、监控彻底解耦

同样是搭 Agent，差距很大。

有的人把模型调用、工具执行、任务调度、状态存储全部堆在一个服务里。一旦崩溃，全部崩溃。

有的人会拆成五个独立组件，每个组件只做一件事。一个环节坏了，其他环节还能跑。

3.1 架构分层

推荐拆成如下五个角色：

组件	职责
model-router	模型路由与负载均衡，根据任务类型选择模型、处理模型故障转移
tool-gateway	工具调用代理，统一 ACL、超时控制、重试机制、调用日志
task-orchestrator	任务状态机管理，负责任务分解、流程控制、异常处理
state-store	任务状态持久化，支持恢复和审计
observability	Token 消耗、工具调用、错误率、延迟分布的可视化

3.2 整体链路

用户发起请求 → model-router 分析意图 → task-orchestrator 创建任务 → 根据任务调用 tool-gateway → 工具返回结果 → 模型生成响应 → 更新任务状态 → 返回用户。

每一步都有独立状态和日志。任意环节失败，都可以单独重试或回滚。

3.3 为什么一定要解耦？

因为模型调用的第一职责应该是：

快速接收请求
轻量校验
异步处理
快速响应

而不是：

做复杂事务
查多张表
做长时间阻塞
参与高冲突状态更新

一旦模型调用层承担太多业务逻辑，系统会同时失去三件事：

响应速度
扩容弹性
故障隔离能力

四、核心数据模型设计

4.1 提示词分层模型

不要把所有提示词写成一个万能 prompt。建议拆成三层：

# SOUL.md 系统层：角色定位和权限边界 你是我的自主操作者和思考伙伴。 你不是客服，不是情绪伴侵，不是文案润色机。 你是参与工作的人。  权限边界： - 可以自动执行：搜索、查询、生成报告、提交代码审查。 - 必须人工批准：发布、购买、删除不可恢复的数据。 - 必须带证据反驳：每一次反对都要有数据、例子、推理。  # TASK.md 任务层：当前任务目标 当月核心目标：将日报生成时间从 30 分钟压缩到 5 分钟以内。 正在推进的任务： - 日报自动化（进度 80%） - RSS 筛选优化（进度 50%） - 代码审查插件（进度 30%）  停滞或变弱的项目： - 自动化邮件回复（已暂停 2 周，建议删除）  # CONTEXT.md 上下文层：当前状态和历史决策 今日已执行任务： - 早报生成（完成，消耗 0.3 美元） - 日报生成（完成，消耗 0.5 美元）  昨日异常： - 代码审查插件调用失败 3 次（GitHub API 限流）

设计要点：

SOUL.md 只在实例启动时加载一次，不参与每次任务上下文
TASK.md 每周更新，任务完成后检查是否需要调整优先级
CONTEXT.md 每日更新，记录当天执行记录和异常

4.2 工具 ACL 模型

不要给所有工具全部权限。建议按三个维度分级：

tools:   - name: github_search     permission: readonly     timeout: 10s     retry: 3     require_approval: false    - name: database_query     permission: readonly     timeout: 30s     retry: 2     require_approval: false    - name: database_migrate     permission: write     timeout: 300s     retry: 1     require_approval: true    - name: deploy_production     permission: write     timeout: 600s     retry: 1     require_approval: true     allowed_hours: "09:00-18:00"

4.3 状态存储模型

建议 SQLite 或 PostgreSQL 存储任务状态，而不是全部放在内存里。

CREATE TABLE tasks (     id TEXT PRIMARY KEY,     type VARCHAR(32) NOT NULL,     status VARCHAR(16) NOT NULL DEFAULT 'pending',     priority INTEGER NOT NULL DEFAULT 5,     created_at TIMESTAMP NOT NULL,     started_at TIMESTAMP,     completed_at TIMESTAMP,     input_json JSON NOT NULL,     output_json JSON,     error_msg TEXT,     token_used INTEGER DEFAULT 0,     tool_calls JSON,     retry_count INTEGER DEFAULT 0,     parent_id TEXT REFERENCES tasks(id) );

原则很简单：

任务是一等公民，每个任务都有完整的生命周期记录
失败可追溯，可以看到是哪个工具响应超时、哪个模型返回了异常
成本可统计，每个任务的 Token 消耗都被记录

五、安全边界：为什么"零信任"比"全开"更稳？

5.1 权限控制的本质

很多人的 Agent 权限设置是这样的：

不能删除数据。但可以查询、可以修改。

问题是：修改和删除的边界是什么？如果 Agent 把数据更新成了错误值，和删除有什么区别？

真正有效的权限模型是：

默认只读
：所有数据库查询默认只返回前 100 条，不能更新
写操作需二次确认
：任何 update/delete 都需要人工确认
可逆操作先执行
：修改前先自动备份
时间窗口限制
：发布、重启等高风险操作只能在工作时间执行

5.2 代码审查的正确姿势

不要让 Agent 直接将生成的代码提交到生产分支。正确的流程是：

生成代码 → 推送到测试分支
自动化测试通过 → 创建 Pull Request
人工审查通过 → 合并到主分支

Agent 的价值不是省掉人工审查，而是让人工审查更有效率。

六、监控运营：Agent 不是黑盒

没有监控的 Agent 就像没有仪表盘的汽车。你知道它在跑，但你不知道它跑得快不快、油耗多少、是不是快坏了。

同样是用 Agent：

有的人等到月底才看账单，发现超支了再看哪里能省。

有的人每天早上看一眼昨天的消耗分布，哪个任务是成本大户、哪个工具被调用了最多次、哪个模型的性价比最差。然后当天就优化。

6.1 为什么必须有可观测性

生产级 Agent 必须采集以下指标：

指标	说明	告警阈值
token_used_per_task	每个任务的 Token 消耗	单任务超过 5000 tokens
task_success_rate	任务成功率	低于 80%
tool_latency_p99	工具调用 P99 延迟	超过 5 秒
model_error_rate	模型返回错误/异常率	超过 5%
active_tasks	当前进行中的任务数	超过 20

6.2 成本分析的正确姿势

不要等到月底才看账单。建议每天早上看一眼昨天的消耗分布：

哪个任务是成本大户？
哪个工具被调用了最多次？
哪个模型的性价比最差？

基于这些数据，优化策略就是明确的了：

重复性任务用本地小模型或缓存
编排类任务用滑动窗口复用上下文
分类任务用轻量模型，复杂推理才用大模型

七、关键技巧总结

1. 专业动词运用

解耦架构
异步消息队列
状态机管理
零信任权限
可观测性标签
动态阈值

2. 能力维度体现

突出架构设计能力（分层解耦方案）
强调安全中心设计（零信任 + ACL）
展示数据驱动决策（成本分析与优化）
体现全流程管控（任务状态机 + 审计日志）
表现运维思维（监控告警 + 自动恢复）

八、生产检查清单（可直接复制使用）

如果你明天就要上线 Agent，请先对照这份清单：

检查项	标准	状态
模型路由	是否根据任务类型分流到不同模型	□ 已配置 □ 未配置
工具 ACL	所有工具是否有明确的读写权限	□ 已配置 □ 未配置
写操作确认	update/delete/deploy 是否需要二次确认	□ 已配置 □ 未配置
任务状态机	是否能看到每个任务的当前状态	□ 已配置 □ 未配置
成本监控	是否能查看每天的 Token 消耗	□ 已配置 □ 未配置
异常告警	任务失败率超过 10% 是否能收到告警	□ 已配置 □ 未配置
故障回滚	模型超时/工具失败时是否能自动重试	□ 已配置 □ 未配置
审计日志	每次工具调用是否都被记录	□ 已配置 □ 未配置

这份清单没有完成的项越多，上线后的风险就越大。

最后说几句：

很多人赏惜自己花了多少功夫调接了多少插件，却从来没想过：插件是功能，架构是能力。提示词是配置，状态机是工程。

两周前我把 Agent 关了。两周后重新搭了一套。这次接了 7 个插件，而不是 27 个。每个任务都有完整的状态记录。每次工具调用都经过 ACL 授权。每天早上都能看到昨天的消耗报告。

结果是：Token 账单降了 62%。任务失败率从 35% 降到 6%。再没有人和我抱怨"今天的报告又跑偏了"。

不是因为新技术更牛，而是因为这一次，我把它当成了一个需要运维的系统。

你可以不接那么多插件，但你必须知道每一个插件在干什么。

你可以不用那么贵的模型，但你必须知道每一个任务花了多少。

你可以不做那么复杂的架构，但你必须能在故障发生时五分钟内找到问题。

这才是生产级 Agent 该有的样子。

关注本号，回复架构图获取本文涉及的分层架构设计图与 ACL 配置模板。如果你也在生产环境里搭 Agent，留言说说你遇到的最大坑。