之前我写过一个 AI Agent 系列。
那个系列更多是在讲概念、方法论和阶段性总结：Agent 到底是什么，为什么需要工具调用，任务拆解怎么理解，上下文为什么重要，Agent 和普通聊天机器人的区别在哪里。
这些内容有价值。尤其是作为架构师，在带大家开展一个新技术方向之前，先把概念讲清楚很重要。
因为如果团队对 Agent 的理解不一致，后面很容易走偏。
一种常见偏差，是把 Agent 做成“套壳聊天框”：本质还是问答接口，只是在 UI 和话术上包装成 Agent。
另一种偏差，是把 Agent 做成“万能大脑”：什么都往里面塞，写作、审核、修复、记忆、状态、展示全部混在一起，最后既难维护，也难排查问题。
所以前一阶段，我更多是在讲概念。
但概念讲到一定程度，就必须进入实战。
这也是我这段时间没有继续更新系列的原因：不是不做 Agent 了，而是开始带团队把之前讨论过的那些概念，真正放进一个项目里验证。
这个项目是一个 AI Agent 小说创作系统。
它表面上是一个 AI 写作工具，但我真正想验证的不是“AI 能不能写一段小说”，而是：
AI Agent 能不能接管一条真实业务链路，并且做到可观察、可恢复、可持续演进？
这篇文章算是之前 Agent 系列的实战续篇，也算是这个项目推进到当前阶段的一次复盘。
先说结论
这次实战下来，我对 AI Agent 落地有一个更明确的判断：
Agent 的难点不在于让模型回答得更聪明，而在于让它稳定地进入业务流程。
真正进入系统后，很多问题都不是单纯的 prompt 问题，也不是换一个更强模型就能解决的问题。
你会遇到的是这些工程问题：
上下文从哪里来？
工具边界怎么拆？
任务状态怎么记录？
执行过程怎么展示？
失败后怎么恢复？
页面刷新后怎么续上？
模型调用失败后怎么重试？
哪些能力应该交给 Agent，哪些能力应该留在业务服务里？
这些问题解决不好，Agent 就只能停留在 Demo。
这些问题解决之后，Agent 才开始像一个真正的系统能力。
为什么选择小说创作这个场景
很多人听到“AI 小说创作系统”，第一反应可能是：
这不就是让 AI 续写小说吗？
如果只是这样，那确实没必要做 Agent。
一个最简单的 AI 写作工具，大概就是这个流程：
用户输入 prompt
↓
模型生成正文
↓
页面展示结果
这个形态很容易做，也很适合 Demo。
但它离真实创作工作流还差很远。
一章内容能不能用，不只取决于文字是否通顺，还取决于：
是否符合当前作品设定
人物行为有没有崩
世界观有没有冲突
剧情是否承接上一章
风格是否一致
有没有明显 AI 味
有没有钩子和节奏
写完后是否需要审核和修复
是否要沉淀成后续记忆
这就不再是一次模型调用能解决的问题。
它天然是一条多步骤业务链路：
读取作品上下文
↓
生成章节草稿
↓
保存章节
↓
运行编辑审核
↓
按需自动修复
↓
提取长期记忆
↓
生成任务报告
这也是我选择这个场景的原因。
小说创作有长上下文、有结构化数据、有质量标准、有多步骤流程，也有很明确的用户目标。它比普通聊天助手更接近真实业务系统。
所以这个项目的核心不是“做一个 AI 写作按钮”，而是：
用小说创作这个复杂场景，验证一套 AI Agent 工程架构。
当前系统的技术形态
这个项目是一个自托管的全栈系统。
后端主要使用：
FastAPI
SQLAlchemy Async
SQLite
Alembic
AI Gateway
前端主要使用：
React
TypeScript
Vite
Tailwind CSS
Recharts
模型侧目前围绕 DeepSeek 多模型使用，不同任务可以走不同模型。
比如：
正文生成偏创作
结构分析偏推理
审核修复偏稳定输出
拆书分析偏结构化结果
从产品形态看，它是一个 AI 小说创作工作台。
从架构主线看，它更像是一个 AI Agent 工程化实验场。
系统里已经包含这些能力：
多作品管理
角色和世界观管理
大纲和章节管理
写作规则
风格锁
写作技能库
一章质检
编辑审核和修复
记忆提取
Agent 任务编排
任务中心
页面切换恢复
失败重试
这些模块单独看都是业务功能。
但从 Agent 视角看，它们其实是 Agent 可以编排、调用和串联的能力。
这也是我在推进项目时一直强调的架构原则：
不要先造一个万能 Agent。先把业务能力拆清楚，再让 Agent 去编排。
从概念到实战，最先变难的是上下文
之前写 Agent 概念时，经常会提到“上下文工程”。
概念上它很好理解：Agent 执行任务之前，需要知道相关背景。
但落到系统里，上下文会立刻变成一组具体问题：
上下文从哪里来？
是前端传，还是后端查？
角色、世界观、大纲、规则怎么组织？
当前章节要不要带上一章？
不同作品之间怎么隔离？
上下文太长怎么办？
风格和禁忌怎么动态注入？
很多 AI 应用早期都会这么写：
你是一个小说作者。
请根据下面的角色、世界观、大纲，写第 10 章。
然后把所有内容拼进 prompt。
Demo 阶段当然可以。
但系统一旦支持多个作品、多个角色、多个章节、多个规则，问题马上出现：
prompt 越来越长
上下文来源越来越乱
不同作品容易串上下文
规则和风格很难复用
前端和后端到处拼字符串
所以在这个项目里，我没有让前端到处拼 prompt，而是把上下文构建收敛到后端服务。
Agent 执行任务时，会从数据库动态读取：
Novel
Character
WorldSetting
OutlineItem
WritingRule
WritingStyle
Chapter
Memory
再由后端统一组装成 system prompt。
这样做有几个好处：
上下文来源可控
多作品之间天然隔离
规则和风格可以复用
Agent 不依赖前端拼接细节
后续可以继续接入记忆、检索和压缩策略
这里解决的不是“prompt 写得更华丽”，而是一个更基础的问题：
Agent 到底基于什么事实执行任务？
从架构角度看，上下文是 Agent 的输入边界。
如果上下文来源混乱，Agent 后面再聪明，也会在错误事实上做决策。
Agent 不是万能函数，而是业务编排层
做 Agent 项目时，很容易有一个冲动：
能不能做一个通用 Agent，让它自己规划、自己调用工具、自己解决所有问题？
我的选择是先不做。
第一版只支持一个高价值任务：
write_chapter_loop
也就是单章节写作闭环。
这个任务里，Agent 不直接包办所有事情，而是编排已有业务能力：
上下文构建
AI 生成
章节保存
编辑审核
自动修复
记忆提取
任务报告
每个能力都有自己的边界。
Agent 负责把它们串起来，决定流程怎么走、状态怎么记录、失败怎么处理、结果怎么沉淀。
这也是我目前对 Agent 工程比较明确的一个判断：
Agent 不应该是一个什么都干的巨型函数，而应该是业务能力的编排层。
如果业务能力本身没有拆清楚，Agent 只会把复杂度集中到一个更难维护的地方。
所以在这个项目里，Agent 编排层不替代现有业务服务。
它更像是站在业务服务之上的一层流程控制：
业务服务负责能力
Agent 负责流程
数据库负责状态
前端负责表达
这个边界一旦守住，后续演进会轻很多。
要增加一个新能力，不一定要改 Agent 的核心逻辑，可以先把能力沉淀成服务，再让 Agent 编排它。
这和流程引擎有什么区别
写到这里，可能有人会问：
这不就是一个流程引擎吗？
这个问题非常关键。
如果只看第一版的 write_chapter_loop，它确实有很强的流程引擎味道：
加载上下文
生成草稿
保存章节
编辑审核
自动修复
提取记忆
生成报告
这些步骤是预先定义好的，执行顺序也是明确的。
所以我不会把它包装成一个“完全自主 Agent”。
更准确地说，当前阶段是：
用流程引擎式的确定性骨架，承载 LLM 的不确定性能力。
流程引擎擅长的是确定性编排：
步骤顺序固定
输入输出结构固定
失败分支预先定义
状态流转可预测
它适合处理审批流、订单流、数据同步流这类规则清晰的业务。
但在这个系统里，有几类事情不是传统流程引擎擅长的：
根据作品上下文理解这一章应该怎么写
判断审核问题是否值得自动修复
从正文里提取可沉淀的长期记忆
根据风格锁和写作规则调整生成策略
在后续版本中根据任务结果选择下一步工具
这些地方需要模型参与理解、判断和生成。
也就是说，流程引擎解决的是“步骤怎么走”，Agent 要进一步解决的是“在上下文里怎么判断、怎么调用能力、怎么产生结果”。
所以我对当前架构的定位不是“Agent 替代流程引擎”，而是：
Agent 站在流程骨架之上，把上下文理解、工具调用、质量判断和结果沉淀串起来。
第一版选择固定流程，是刻意克制。
因为在真实业务里，一上来就做完全开放的自主 Agent，风险很高：
执行路径不可控
失败原因难定位
用户很难理解它在做什么
调试和回放成本高
业务边界容易失控
所以我更倾向于先把底座做稳：
流程可控
状态可查
步骤可见
失败可追踪
结果可回放
然后再逐步把更动态的能力放进去。
比如后续可以让 Agent 根据审核结果决定是否进入修复，让它根据章节质量决定是否追加风格检查，让它根据作品进度选择不同写作技能。
这时它就不只是固定流程，而是在可控骨架里逐步增加决策能力。
这也是我认为 Agent 工程落地比较现实的一条路径：
不要一开始追求完全自主，而是先用工程化流程托住 Agent，再逐步释放 Agent 的决策空间。
为什么要做 AgentTask 和 AgentStep
如果 Agent 只是一次模型调用，你不太需要任务系统。
但当 Agent 开始执行多步骤流程，就必须记录状态。
否则用户只能看到一个“生成中”。
一旦任务跑得久一点，或者页面刷新、接口失败、服务重启，问题就会全部暴露出来。
所以后端加了两个核心模型：
AgentTask
AgentStep
AgentTask 表示一次完整任务。
比如：
为某个作品写第 12 章
AgentStep 表示任务里的每一个步骤。
比如：
加载上下文
生成草稿
保存章节
编辑审核
自动修复
提取记忆
生成报告
任务状态包括：
pending
running
completed
failed
cancelled
interrupted
步骤状态包括：
pending
running
completed
failed
skipped
有了这套状态之后，Agent 不再是黑盒。
前端可以展示它做到哪一步。
后端可以记录每一步的输入输出。
失败时也能知道到底是生成失败、审核失败，还是记忆提取失败。
这一层看起来不炫，但它非常关键。
因为真实业务系统里，用户关心的不只是“最终有没有结果”，还关心：
现在跑到哪一步了？
为什么失败？
能不能取消？
能不能重试？
刷新页面后还能不能看到？
这就是 Agent 从演示走向产品能力必须补上的工程底座。
这段时间项目主要推进了什么
这段停更时间，项目主要推进的是 Agent 工程化能力。
包括：
Agent 写作闭环编排
Agent 任务中心页面
长任务页面切换恢复
Agent 任务重试能力
长任务旧状态清理
这些工作本质上都在回答同一个问题：
Agent 进入真实业务流程之后，怎么稳定地跑完？
真实系统一定会遇到这些情况：
任务跑一半页面刷新怎么办？
用户切换页面后还能不能看到进度？
重复点击会不会创建多个任务？
AI 调用失败后怎么重试？
服务重启后 running 状态怎么处理？
失败任务怎么定位原因？
这些问题不解决，Agent 就只能停留在演示。
解决之后，它才开始像一个产品能力。
对架构师来说，这一阶段不是在堆功能，而是在补 Agent 系统的工程底座：
任务持久化
步骤可观察
失败可追踪
状态可恢复
用户可感知
这也是我认为很多 Agent 项目从 Demo 到业务系统之间，最容易被低估的一段距离。
前端也必须理解 Agent 流程
很多人做 Agent 时，会把重点全部放在后端。
但做下来会发现，前端也很关键。
因为 Agent 是长任务，不是普通接口请求。
如果前端只是展示一个“生成中”，用户会非常没有安全感。
所以系统里做了两层展示。
第一层是写作驾驶舱里的任务面板。
它用于展示当前作品正在执行的 Agent 任务，包括状态、步骤和操作按钮。
第二层是 Agent 任务中心。
它用于查看历史任务、失败任务、重试任务和步骤详情。
这其实是 Agent 产品化里很重要的一步：
用户不只要结果，也要知道 Agent 正在做什么。
当 Agent 接管复杂流程后，前端需要把流程表达出来。
不然用户感知不到系统在工作，只会觉得它卡住了。
所以我现在越来越觉得，Agent 项目不能只从模型和后端看。
它至少有四层：
模型层：负责生成、分析、判断
工具层：负责提供可调用的业务能力
编排层：负责任务拆解、状态推进、失败处理
体验层：负责把 Agent 的执行过程表达给用户
缺任何一层，Agent 都很难成为一个可用产品。
从架构师视角，我更关注什么
这次项目推进过程中，我对架构师在 Agent 项目里的角色也有一些新的感受。
架构师不只是选模型、定技术栈，也不是简单画一张流程图。
更关键的是帮团队守住几个边界：
上下文边界：Agent 能看到什么，不能看到什么
工具边界：哪些能力是工具，哪些只是内部实现
状态边界：哪些步骤必须持久化，哪些可以临时执行
失败边界：哪些失败中断任务，哪些失败只记录 warning
产品边界：哪些过程要给用户看，哪些只进入日志
这些边界如果不提前想清楚，项目越往后越容易变成一团。
尤其是 Agent 项目，很容易被模型能力带着走。
模型看起来什么都能做，于是系统也想什么都交给模型。
但工程系统不能只靠“模型大概会处理”。
它需要明确的数据来源、明确的工具契约、明确的状态流转、明确的失败策略。
这也是我这次从概念转向实战后，最想在系列里继续展开的部分。
这个系列后面怎么写
这篇文章算是一个回归和总览。
之前的 Agent 系列更多是在写概念和总结。
这个新阶段，我会更多结合这个真实项目，写 Agent 从概念走向实战的过程。
后面计划拆这些主题：
Agent 上下文工程：作品、角色、世界观、风格锁如何动态注入
Agent 工具调用设计：写作、审核、修复、记忆提取如何拆边界
Agent 任务状态机：AgentTask 和 AgentStep 如何设计
Agent 长任务体验：取消、重试、中断恢复和任务中心
AI 工程底座：模型路由、限流、错误处理和成本意识
前端驾驶舱：如何把复杂 Agent 流程做成用户能理解的界面
架构师视角：如何带团队把 Agent 从概念推进到可用产品
我会尽量少讲空泛概念，多讲项目里真实遇到的问题。
因为 Agent 真做进系统里之后，你会发现很多问题不是模型问题，而是工程问题、架构问题、产品问题。
最后
这段时间停更，不是因为 Agent 这个方向停了。
恰恰相反，是因为我们把之前讨论过的概念和总结，放进了一个更复杂的真实场景里重新验证。
到目前为止，我最大的感受是：
AI Agent 真正难的不是让模型回答得更聪明，而是让它稳定地进入业务流程。
它需要上下文工程，需要工具边界，需要任务编排，需要状态恢复，也需要前端产品化表达。
小说创作只是这个项目的业务场景。
我真正想验证的是：一个 AI Agent 应用，如何从 Demo 推进到可用系统。
作为架构师，我也会继续从架构设计、任务拆解、工程落地和团队推进的角度，把这个项目的核心模块和踩坑过程写出来。
如果你也在做 AI Agent 应用，尤其是想把 Agent 做进真实业务流程里，可以关注后续更新。
