你好，我是在Agent内发布的文章

软件架构师罗小东，多年架构和平台产品设计经验，目前在Agent场景落地结合中。

场景

这里是SaaS系统，主要针对多部门、多团队的场景。

这里针对于场景多个岗位角色，包括解决方案、项目标书、技术方案、规划设计等场景，前期在做项目管理、还有售前的时候，会比较多遇到，同时包括做架构时。

核心痛点：传统方案高度依赖个人经验，编写重复、质量不稳定、效率低、知识难以沉淀复用。

面向方案设计全流程场景，覆盖多岗位协同工作：

• 售前岗位：解决方案撰写、项目投标文件编制
• 方案岗位：技术方案、总体规划设计、可研报告
• 管理岗位：项目管理方案、培训体系方案、制度流程设计
• 架构岗位：技术架构规划、实施路径设计、交付方案
• ….

能覆盖的能力比较多，可以根据自己的业务进行场景挖掘和匹配，这个是前期沉淀使用的方案编写场景以及过程中的实践。

业务架构设计

构建【“知识 + AI 能力 + 流程工具 + 人工编辑”一体化】的方案智能生成与辅助设计体系，实现从需求输入到方案输出的全链路 AI 增强，提升方案质量、标准化程度与交付效率。

这里是AI驱动方案整体业务架构设计：

详细描述：

1. 业务场景：解决方案、项目标书、技术方案、规划设计、培训方案、管理方案
2. AI智能体能力：
   • 内部知识库：企业内部知识库、网络搜索、方案模板、历史方案、标准模板、技术白皮书、制度规范
   • 外部知识增强：行业政策、公开资料、竞品信息、领域知识
   • AI能力插件：
     • 网络搜索MCP: 结合网络搜索、搜索实时的信息、网站等
     • 章节生成Skill：业务概述、技术架构、实施计划、风险管控、售后保障等
     • 内容抽取Skill：从招标文件 / 需求文档自动提取关键指标、评分点、强制条款
   • 二次编写：
     • 章节重写、文档润色、修改、
     • 章节续写、扩写、缩写、逻辑重组
     • 内部文档分享、评审
3. 业务流程与编排层：
   • 需求解析 → 框架生成 → 章节填充 → 内容润色 → 合规校验 → 人工修订 → 定稿输出
   • 任务拆解与自动分配：每个章节的编写则不同的SKILL结合编写

每个AI场景有不同的设计，这里针对的是方案文档类的解决方案，不同的业务场景根据MCP和SKILL进行能力的扩展。

集成效果

这里是集成效果，集成的是多Agent能力。

场景定义

根据不同的场景自定义知识库、SKILL还有MCP等工具，可以根据不同的场景建议不同的AI，这里是多AI的结合，可以根据不同的场景来匹配不同的AI。

一般定义好场景之后，直接使用即可，这样会降低使用门槛，比较高级的可以自定义切换AI，每个AI可以选择和匹配不同的知识库、还有SKILL，包括MCP，模型能力等。

这样每个不同的AI会实现不同的场景，比如售前的AI使用的是售前的知识库和SKILL，而技术的AI使用的是技术的知识库和SKILL …. 当然如果是教育场景，也可以建立AI老师。

另外一个是方案模板库，每个文档或者方案会有不同的模板，进行更精确的场景匹配。

这里配置一般只是一次配置即可，后续一般不会变动，前端直接使用即可。

使用方式

在使用的时候，直接上传需求或者对应的内容，然后输出方案的要求即可。内置角色模板（如需求分析专员、技术架构专员、实施方案专员等），按角色分工自动生成对应章节内容，支持多人并行协作与审阅流程。

AI在接收到需求之后，进行拆分、编写，过程可视化，用户在调整或提交资料后，文档处理与方案生成由后台异步任务执行，生成结果纳入统一任务管理平台，支持进度跟踪、重试、审计与统一检索。

支持针对指定章节或选中文本进行重新生成，用户可保留上下文或替换部分内容，快速迭代方案表述与技术细节。在重写时自动保持文档上下文与引用一致性。

生成后的方案支持在线编辑、实时保存与版本管理，最终可导出为Word并保持与原文档结构一致，便于交付与归档。

总结

针对传统方案编写过度依赖个人经验、重复劳动多、质量参差、知识难以复用等痛点，搭建 “知识 + AI 能力 + 流程工具 + 人工编辑” 一体化智能方案生成体系。

体系整合内外部知识库与 AI 插件能力，覆盖需求解析、框架生成、内容润色到合规定稿的全流程，通过多 Agent 协同实现分角色、分章节智能编写。

上面是目前的一些AI+方案实践经验，这里也是期望给一些朋友参考。

软件架构师罗小东，多年架构和平台产品设计经验，目前在Agent场景落地结合中。

场景描述

这里针对的主要是开发过程中的痛点做的Agent助理设计方案，也是前期团队一直在使用的方式。

开发团队每周/每日需耗费大量时间整理项目进展、梳理开发内容、排查项目风险、项目整体复盘、撰写工作周报这些会比较耗时，有些情况下甚至需要半天来整理这些内容。

过程容易出现内容遗漏、问题反馈不及时、数据统计不精准；难以快速把控整体、技术债务风险，缺乏科学健康度评估依据（经验），管理与项目推进效率受限。

这里的AI助理就是针对于上面的解决方案，针对于不同的业务场景，每个设计师有不同的设计，我有我思。

整体业务架构

下面是整个Agent助理的业务集成设计，从下往上设计：

详细描述如下：

1. 项目环境：单项目、多项目、代码仓库、团队组织
2. 项目过程：周报、日报、风险、团队管理、项目进度、培训(技术/业务)、帮带管理、任务安排
3. Agent助理：AI整理周/日报、AI工作安排、AI风险识别、AI培训方案、AI项目复盘、AI培训计划、AI技术方案

针对角色的AI赋能场景，可以结合的内容很多，这里只是列举几个场景：

• 项目助理：AI 自动汇总整理日报周报、同步项目进度、梳理基础事项，替代人工统计、文案编写与日常事务跟进。
• 技术组长：AI 辅助识别项目风险、编排团队任务、生成技术方案、制定培训计划并完成阶段性项目复盘。
• 开发人员：AI 自动生成工作日报周报、拆解分配开发任务、推送学习资料，减少文案负担，聚焦代码开发。
• ….

集成效果

这里做一个闭环的形成，做的简单场景演示，针对于开发过程中的演示，实现过程的周日报整理：

• 获取项目周日报整理，对项目过程文档编写进行减负；
• 自动提取本周开发内容，任务管理工具及开发日志，自动抓取本周核心开发内容，无需手动录入以减少重复工作量。
• 识别问题、风险、阻塞点，还有个人的工作计划安排参考。
• 自动汇总成果与计划

以下为集成效果：

下面这个是通过整个项目的复盘还有后期的进一步评估和分析集成，类似于数据挖掘一样的。

• 分析项目情况分析，包括团队、工作安排、人员等情况进行综合分析；
• 项目健康评分，团队还有工作安排的合理性进行评估等；
• 技术债务风险，后期遗留的项目风险点还有过程遗留的未完成的进一步的评估；
• 团队管理指导，针对于项目情况，可针对性定制团队的培训计划（团队的成长计划）

以下为集成效果:

每个场景都可以，直接生成可发送飞书文档，或者整理成Excel文档下载。

总结

本方案围绕研发团队项目管理痛点，设计落地 AI 项目助理 Agent 体系。

依托多项目、代码仓库等底层环境，覆盖日报周报、风险管控、任务管理、团队培养等全流程场景，针对不同角色实现差异化 AI 赋能。通过自动抓取研发数据、智能内容汇总、风险识别与项目健康度评估，全面提升研发管理效率与团队协作水平。

上面是目前的一些AI+项目实践经验，这里也是期望给一些朋友参考。

概述

基于AIP在运维场景上的实践。传统运维方式便宜人工经验和手工，大部分还是偏于个人能力和人力运维，熬夜、排查很依赖人工。

下面是一些常见的行业系统运维痛点，也是目前遇到比较多的：

1. 运维对象繁杂，命令行多、系统多
2. 故障依赖人工排查，定位周期长、效率低
3. 日常事务过载，运维报告多、工单内容多
4. 多环境，排错链路长，问题定位困难
5. 监控数据分散，无法全局掌握系统状态
6. 日志量大且杂乱，问题溯源耗时费力
7. 经验依赖度高，核心运维能力不可沉淀
8. …

这些在很多程度上，可以用AI来解决这个问题，也很合适使用AI来解决，整体方案如下，从下往下：

这里主要是整体AI运维架构设计：

• （系统层）docker、k8s、操作系统、业务系统、nginx、Devops、mysql、中间件
• （业务层）安全监控、系统监控、业务监控（数据库）、性能监控、访问监控、黑名单、日志监控、自动化操作、预警管理、日常运维报告、工单管理、故障排查、容量规划、备份恢复等
• （AI层）系统运维Agent（AI运维大脑）

整体设计有些中规中矩，偏向于中小型项目和团队运维管理，非常合适内部多个环境场景，比如开发环境、测试环境。

每个设计思路不一，我有我思。

整体AI+运维设计

运维集成的技术架构设计：

这里大概分两个点阐述，主要是技术说明还有连接方案：

1. AI接管运维工作：

• AI智能体进行运维接管，这里设置安全界限、禁止型命令、防越界
• AI执行过程可视化，可监控、过程可追溯
• 执行操作和数据在内部业务服务器，不对外
• 联通飞书、钉钉等报告场景能力，形成报告

1. 业务服务器接管管理

• 使用websocket安全wss，内网可以连接，内网离线操作（或是跳板机）
• 连接过程安全加密、单独数据通道、动态密钥配置
• 线上线下自定义连接管理，统一管理系统和管理面板

这样有点类似于OpenClaw，你可以把密钥还有各种数据都在本地操作，然后由一个统一的管理平台进行管理。

集成效果

针对于运维管理集成的SKILL能力，集成Kubernetes和服务器管理能力SKILL。

基于日志实时解析网站动态，深度分析访问流量趋势、用户行为特征，结合风险库自动封禁恶意地址。

实时解析Nginx访问日志，统计PV、UV及地域分布，输出ECharts流量趋势与热力图洞察。

总结

传统运维高度依赖人工，存在运维对象繁杂、故障排查慢、数据分散、经验难沉淀等痛点，人工成本高且效率低下。

本次实践构建分层AI运维架构，以AI运维Agent为核心，对接底层系统与全场景运维业务。通过AI智能体安全接管运维工作，搭配WSS安全通道实现服务器统一管理，操作可追溯、数据不外露，并联动办公平台自动生成报告，有效解决传统运维难题。

上面是目前的一些AI运维实践经验，这里也是期望给一些朋友参考。

软件架构师罗小东，多年架构和平台产品设计经验，目前在Agent场景落地结合中。

背景

这里针对的是AI体验版的数据，因为要迁移数据库，刚好做了一个统计，临时记录，会偏向于口语化一些。

当前一直是AI平台体验版对外，更多是合作伙伴还有部分注册用户使用，前期一直专注于产品的开发，没有太多体验用户，在这一年里面积累下来的体验数据。这里拿了两个数据，一个是AI写方案的数据，一个是AI对话的，目前后台对话的次数是605987次，然后生成的AI文档数据是161122份。当然还有其它的场景，这里就不做统计。

因为前期更多是为了给有合作的伙伴、兴趣的朋友、用户体验进行体验，这个量确实有点超过我们的预期。

但总的来说，这个数据体验还比较少，但是对于AI平台来说，或者对我们团队来说，是一个阶段性的反馈，因为我们每次对话更多的是Agent对话，文档是多Agent来(多循环)处理的，可能数据级来说，应该还会更多出几个级别。

我们是自研的Agent平台，使用SpringBoot技术，底层框架(类似于langchain)也是我们自己搭建，包括前端。相对来说，可能会其它使用开源平台的有些不一样的（比如Dify），记录的经验大概有以下几个点：

• Agent前期稳定性及上下文
• 自定义全局Prompt及优化
• Agent的对话和工具优化
• 多Agent和后台任务的管理

你会发现这里很少讲Token费用的问题，主要是国内的Token成本比较低，另外就是AI文档的输出价值性较高（类似于你熬夜写方案还是AI写一份方案的对比）。这里的经验更多偏向于Agent平台过程问题及经验总结，每个架构师有自己的思路，我有我思。

过程记录

Agent并不是大模型，这里是 AI 工程化，并不是大模型的，类似于我们不做电厂，但是我们会用电来做特斯拉工厂，而Agent就是我们的 Model3 产品。

前期稳定性及性能问题

稳定性是我们最大的忌讳之一，不管是模型还是Agent，基本上你很难接受执行过程中出现断掉的，这好比看电影，可以接受画质模糊一些，但是不能接受一卡一卡的，特别是完全卡死的情况。

前期这个问题主要出现几个地方，一个是模型能力，另一个是底层框架，还有一个是上下文的处理。

在Agent处理上，仅仅是简单的对话，这个可能相对来说会好一些，但是Agent的操作过程中多步的，有推理的，这个时候，就需要高级的模型能力，另外在多Agent的时候，还会存在并发的问题。比如Planing模式，规划出来了很多步骤，执行的时候几十个任务执行 …. 前期的稳定性问题，会造成是否可用的关键点。

在工程上做了限制，由并行改成成串行，避免了多线程并发问题，可以慢一些，因为有可能会同时执行十几个Agent，考虑到稳定性，将所有的都改成串行，要保障使用性上能稳定。

另外就是底层框架上不要使用外部的开源框架，重新封装，然后做好多个场景下的异常重试机制。这个前期的时候，也是考虑了很久，维护一个框架的成本并不低，但是后面的时候，优势就比较体现，比如可以随时加可观测能力，还有用户权限的控制等。

在模型的选择上，目前只考虑阿里或者字节两家，其它的基本上不考虑，在体验环境里面，印象里除了一两次敏感字眼出现异常以外，其它基本上都是比较稳定，至少没有反馈说无法使用的情况，还有后台报异常的时候，是模型的无响应或者限流等异常，有过，但是概率很低，基本不会出现。

再有一个是交互也是类似，如果卡住无响应，这也是很难以让人接受的，包括过程缺少步骤，看不出AI思考过程等，这个过程ManusAI效果就是很好。

接下来就是上下文的技巧，这里主要是压缩，还有上下文窗口丢弃策略，目前的大模型上下文长度比较大，这里主要是聚焦和过程压缩，还有去掉多余历史记录。如果长任务使用规划再到执行，单个Agent对话每次不能超过15次迭代，超过的就做防御性总结。当然还有很多上下文技巧，比如Skill技巧，约定规则，任务模版，动态拼接、历史顺序，知识库处理，内置工具工具等，主要还是是稳定性为主。

自定义全局Prompt及优化

这个是主要的点，优化的内容很多。

一个是约束和自定义底层框架。目前实现Agent的思路，前期主要是ReAct和CodeAct两个结合，后面再加上了部分System 2 ，这样从防御性原则上，该有执行能力上，通用能力做好约束，无论如何，就是不要让太多的Prompt和历史对话混乱在一起，如果任务点比较多的，就会分开执行不同的任务，比如CodeAct触发的时候，会跟主线的Agent分开，做好之后结果再返回给主Agent，后面很多思路都是这个。按场景加载，另外就是子任务（也可以理解成subagent）的上下文分开，不要污染主任务。

优化的部分，还有各个工具的优化包括Sandbox还有预装环境，包括Python还有docker，数据的预先解析，比如OCR，主要是能做到先做，合并起来，这个有好有坏，会消耗很多上下文，但是耐不住速度快还有稳定，就是能固定程序的就固定，还有提供出来。

这些就需要过程中调试好Prompt，基础的Prompt模版，前期看过其他开源项目的prompt，但是你会发现，不同的工具他们本身结合的工具，Prompt都是互相匹配的，比如CrawAI、LangGraph、GaminaCli等，也尝试过直接参考，但是调试下来，基本上都是千差万别的。

在这个过程中，定义好全局的Prompt模版、动态拼接过程优化也是消耗了不少时间。

Agent的对话和工具优化

在自研Agent平台的实际体验版运行中，对话与工具的联动效果直接决定用户可用感，我们围绕思考可见性、执行流畅度、工具可靠性、对话可控性做了大量针对性优化，核心经验如下：

对话过程可视化，避免“黑盒卡顿”，参考ManusAI等优秀产品的交互逻辑，放弃纯结果输出模式，把Agent推理、工具调用、步骤执行的中间状态流式推送前端。用户能清晰看到AI在思考什么、调用了哪个工具、执行到第几步，既解决无响应焦虑，也方便排查异常。同时对长对话做步骤分段，单轮对话迭代严格控制在合理区间，超出则自动触发阶段性总结，防止上下文膨胀导致的响应变慢。

工具调用规范化，减少无效执行，统一工具入口与调度逻辑，内置工具（知识库、沙箱、OCR、代码执行等）与自定义工具做标准化封装，避免工具参数混乱、调用失败。针对Sandbox、Python环境、Docker等执行环境，提前做好预装与预热，数据解析（如文档OCR、格式转换）前置处理，减少Agent实时计算压力，提升工具调用成功率。

对话与工具解耦，防止互相干扰，主对话Agent专注意图理解与任务分发，工具执行交由专用子Agent处理，执行完毕后只把精简结果回传主Agent，不把工具执行日志、冗余参数带入主上下文。同时建立工具调用失败兜底策略：异常自动重试、超时自动终止、失败给出明确提示，避免单次工具异常导致整段对话崩溃。

动态Prompt适配工具场景，不同工具匹配专用对话Prompt模板，而非一套通用Prompt适配所有场景。比如代码工具触发时自动加载CodeAct专属Prompt，规划任务时切换为Planning模式Prompt，通过动态拼接保证对话指令与工具能力高度匹配，既提升执行准确率，也降低上下文混乱概率。

用户交互体验优化，支持对话中断、重新提问、步骤回退，避免一旦启动多步执行就无法干预的问题；对敏感内容、模型限流、无响应等异常做友好提示，而非后台静默报错；同时对AI文档生成这类重工具场景，对话只保留核心指令，减少无关闲聊占用上下文，保障工具执行效率。

多Agent和后台任务的管理

体验版中大量AI文档为多Agent循环协作生成，对话也存在主从Agent配合，因此多Agent调度与后台任务治理是保障平台稳定的核心，相关实践总结如下：

串行优先，严控并发，保障稳定性，早期多Agent并行执行（Planning模式批量任务）频繁出现线程冲突、资源抢占、模型限流叠加等问题，直接导致任务中断。后续全部改为串行执行，放弃并行速度换取整体可用度，即使同时触发多个Agent任务，也按队列依次执行，避免并发带来的不可控异常。

主从Agent架构，职责清晰不污染，采用“主Agent统筹+子Agent专项执行”模式：主Agent负责用户意图解析、任务拆解、结果汇总与上下文管理；子Agent（SubAgent）专注单一任务，如代码执行、文档生成、数据解析、规划落地等。子任务独立上下文、独立生命周期，执行完成后销毁，不污染主Agent对话历史，也避免多任务之间互相干扰。

后台任务队列化，支持异步与可观测，对耗时任务（长文档生成、多步骤规划、批量工具执行）统一放入后台任务队列，前端展示任务进度，不阻塞前端对话。任务状态实时同步：待执行、执行中、成功、失败、异常终止，支持查看执行日志。同时自研框架内置任务可观测能力，可追踪每个Agent的调用链路、耗时、异常点，方便快速定位问题。

任务超时与防御机制，防止死循环，为每个Agent任务设置执行超时时间，单Agent迭代次数上限、多Agent循环次数上限，超出则强制终止并做防御性总结，避免因模型思考发散、工具死循环导致资源耗尽。后台任务支持手动取消、自动重试，对无响应任务做主动中断，释放服务器资源。

资源隔离与权限控制，不同Agent任务做资源隔离，防止单个任务异常影响整个平台；结合用户权限体系，对后台任务做权限校验，避免越权调用工具或执行高危操作。自研框架的灵活性在此体现明显，可快速适配多Agent场景下的权限、资源、日志等管控需求。

总结

这一年AI平台体验版的运营数据与实际落地经验，虽整体体验用户规模仍偏初期，为自研Agent平台交出了阶段性的实践反馈。目前更专注于AI工程化落地与Agent体系打磨，全程围绕稳定性优先、体验可控、架构自主可控的思路推进。

每个产品设计思路不一，这个是建设Agent平台的一些经验，期望给有兴趣的朋友参考，也欢迎交流。