此前我撰写过一系列关于AI Agent的文章，当时更侧重于阐述概念、方法论与阶段性总结：Agent的本质究竟为何、为何需要工具调用、如何理解任务拆解、上下文的重要性，以及Agent与普通聊天机器人的核心差异。
这些内容具有相当的价值，尤其是对于架构师而言，在带领团队探索新技术方向之前，率先厘清概念至关重要。因为倘若团队成员对Agent的理解存在分歧，后续开发极易偏离正轨。
一种常见的误解，是将Agent简单地封装成“套壳聊天框”：本质上仍是问答接口，仅在UI和话术层面包装成Agent。另一种误区，则是将Agent视为“万能大脑”：将所有功能——写作、审核、修复、记忆、状态、展示——全部混为一谈，最终导致系统难以维护，问题排查也困难重重。
因此，前一阶段的核心在于概念普及。但概念阐述到一定程度，就必须进入实战环节。这也是这段时间该系列暂未更新的原因：并非搁置Agent，而是开始带领团队将之前探讨的那些概念，真正落地到一个实际项目中进行验证。
这个项目正是一个AI Agent小说创作系统。从表面看，它是一款AI写作工具，但真正希望验证的并非“AI能否写出一段小说”，而是：
这篇文章既是此前Agent系列的实战续篇，也是该项目推进至当前阶段的一次系统性复盘。
先说结论
经过此次实战，我对AI Agent的落地有了更为清晰的判断：
真正融入业务系统后，许多问题已不再是单纯的prompt工程问题，也并非更换一个更强大的模型就能迎刃而解。你将面临的是这些工程层面的挑战：
上下文从何而来？工具边界如何划分？任务状态怎样记录？执行过程如何展示？失败后如何恢复？页面刷新后如何延续？模型调用失败后如何重试？哪些能力应交给Agent，哪些能力应保留在业务服务中？
这些问题若得不到妥善解决，Agent只能停留在Demo阶段。只有解决它们，Agent才能开始展现出真正的系统能力。
为什么选择小说创作这个场景
许多人在听到“AI小说创作系统”时，第一反应可能是：若仅此而已，确实没必要引入Agent。
一个最简单的AI写作工具，大致遵循以下流程：
用户输入 prompt → 模型生成正文 → 页面展示结果
这种形态易于实现，也适合Demo展示。但它距离真实的创作工作流仍有很大差距。
一章内容是否可用，不仅取决于文字是否通顺，还需要考量：是否符合当前作品设定、人物行为是否保持一致、世界观是否存在冲突、剧情是否与上一章衔接、风格是否统一、是否带有明显AI痕迹、是否具备故事钩子和节奏感、完成后是否需要审核与修复、是否需沉淀为后续记忆。
这不再是一次模型调用就能解决的问题。它天然构成一条多步骤的业务链路：
读取作品上下文 → 生成章节草稿 → 保存章节 → 运行编辑审核 → 按需自动修复 → 提取长期记忆 → 生成任务报告
这也是选择该场景的原因所在。小说创作具备长上下文、结构化数据、质量标准、多步骤流程以及明确的用户目标。它比普通聊天助手更贴近真实的业务系统。
因此，该项目的核心并非“打造一个AI写作按钮”，而是：
当前系统的技术形态
这是一个自托管的全栈系统。
后端主要采用：FastAPI、SQLAlchemy、AsyncSQLite、Alembic、AI Gateway。
前端主要使用：React、TypeScript、Vite、Tailwind CSS、Recharts。
模型侧目前围绕DeepSeek多模型体系，不同任务可调用不同模型。例如：正文生成偏向创作、结构分析偏向推理、审核修复偏向稳定输出、拆书分析偏向结构化结果。
从产品形态来看，它是一个AI小说创作工作台。从架构主线上审视，它更像一个AI 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，让其自主决定一切。但我们选择先不这样做。
第一版只支持一个高价值任务：write_chapter_loop，即单章节写作闭环。在这个任务中，Agent并非包办所有事情，而是编排已有的业务能力：上下文构建、AI生成、章节保存、编辑审核、自动修复、记忆提取、任务报告。
每项能力都有其明确的边界。Agent负责将它们串联起来，决定流程如何推进、状态如何记录、失败如何处理、结果如何沉淀。
这也是目前对Agent工程比较明确的一个判断：如果业务能力本身没有拆解清楚，Agent只会将复杂度集中到一个更难以维护的地方。
因此，在这个项目中，Agent编排层并不替代现有业务服务。它更像是站在业务服务之上的一层流程控制：业务服务负责能力，Agent负责流程，数据库负责状态，前端负责表达。
一旦守住这个边界，后续的演进会轻松许多。要增加一项新能力，不一定需要修改Agent的核心逻辑，可以先将其沉淀为服务，再让Agent编排它。
这和流程引擎有什么区别
写到这里，可能有人会问：这不就是工作流引擎吗？
这个问题非常关键。如果只看第一版的write_chapter_loop，它确实带有很强的流程引擎色彩：加载上下文、生成草稿、保存章节、编辑审核、自动修复、提取记忆、生成报告。这些步骤是预先定义的，执行顺序也明确。
因此，我们不会将其包装成一个“完全自主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任务重试能力、长任务旧状态清理。
这些工作本质上都在回答同一个问题：
真实系统一定会遇到这些情况：任务运行一半页面刷新怎么办？用户切换页面后还能否看到进度？重复点击是否会创建多个任务？AI调用失败后如何重试？服务重启后running状态如何处理？失败任务如何定位原因？
这些问题不解决，Agent就只能停留在演示阶段。解决之后，它才开始像一个真正的产品能力。
对于架构师而言，这一阶段并非在堆砌功能，而是在补全Agent系统的工程底座：任务持久化、步骤可观察、失败可追踪、状态可恢复、用户可感知。
这也是我们认为许多Agent项目从Demo到业务系统之间，最容易被低估的一段距离。
前端也必须理解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这个方向停滞了。恰恰相反，是因为我们将之前讨论过的概念与总结，放入了一个更复杂的真实场景中重新验证。
截至目前，最大的体会是：Agent真正落地，靠的不是一个更聪明的模型，而是一整套工程能力。它需要上下文工程，需要工具边界，需要任务编排，需要状态恢复，也需要前端产品化的表达。
小说创作只是这个项目的业务场景。真正希望验证的是：一个AI Agent应用，如何从Demo推进到可用的系统。
作为架构师，我会继续从架构设计、任务拆解、工程落地和团队推进的角度，将这个项目的核心模块与踩坑过程记录下来。
如果你也在做AI Agent应用，尤其是希望将Agent融入真实业务流程中，可以关注后续的更新内容。
