月度归档:2026年04月

我让AI接管日常运维方案和实践

概述

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

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

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

这些在很多程度上,可以用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运维实践经验,这里也是期望给一些朋友参考。

我从16万份文档和60万次对话总结的Agent平台经验

软件架构师罗小东,多年架构和平台产品设计经验,目前在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平台的一些经验,期望给有兴趣的朋友参考,也欢迎交流。

我对AIP版Claw的龙虾产品设计及实践

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

概述

这里的Claw只是架构上类似,但是并非完全照搬OpenClaw设计,形成自己的AIP版Claw(以下简称Claw)能力。

Claw设计思路

使用统一管理平台跟Claw主机关联模式,这样就形成了一个管理平台,管理多个本地主机Claw的能力,同时弱化了Claw本地的能力,强化线上统一管理平台。

  • 线上跟线下主机结合,这里使用WebSocket(HTTPS)及双向加密,然后定时心跳机制;
  • Agent可以关联多个线下Claw本地主机,将SKILL架构和Agent能力搬到云上,类似于ManusAI+本地Claw的结合;
  • 移动端跟微信小程序关联一起,因为Agent过程的持续输出,流程信息比较关键;
  • Claw代码执行的沙箱移到了统一的Sanbox管理,每个对话会有单独的Sanbox管理;
  • SKILL能力同样也移到线上进行管控,还有部分密钥,将SKILL与MCP结合,目前暂时不兼容社区本地化script;
  • Claw本地用于保存用户的客户端密钥还有Cli调用能力,包括一些本地化的能力。

智能体(Agent)设计

下面是Agent能力设计,针对于单独整理出SKILL Agent,用于来扩展最新的技术,下面从推理架构、技能融合、知识库、代码执行、上下文、稳定性、可视化、安全几个维度的设计思路:

  • 推理能力:采用ReAct推理架构,深度融合Skill与MCP双技能
  • 工具优化:支持多工具动态加载与自动去重,工具调用更高效
  • 上下文压缩:内置智能上下文压缩,超长对话和内容也能轻松承载,滑动窗口等设计
  • 知识库:动静知识库一体化,支持上传和外挂双RAG检索
  • CodeAct:代码可自动执行并自带重试机制,出错能智能修复
  • SSE流可视化:全程流式响应可视化,每一步都有埋点记录,可追溯
  • 防御性:会话安全可控,支持随时取消,异常全面捕获,更稳定
  • 向量化能力:超大附件自动向量化处理,兼容多种文件格式
  • 防御性处理:达到循环上限自动总结输出答案

整个设计的思路是稳定性还有可靠性为主,同时我们在设计上放弃掉一般人员对Claw的”养龙虾”思维(要玩转还需要周期与成本),调试出来的SKILL也是以稳定性为主。

基础架构

这个设计过程中,你会发现非常的体现Harness架构的优势,下面是原先处理的Agent底层能力,主要包括原来的设计的包括Data、虚拟机、Sanbox、SKILL、插件、工具、MCP、网络、记忆、任务抽取成了底层服务插件。

另外结合k8s的管理扩展,所以Claw在上面建议的时候,直接接入前期的Harness架构。

以下为集成的典型案例情况,案例尽量以实际生产型为主,集成演示多Claw控制,还有线上线下结合的方式。

场景案例

以下为一些典型的集成的已经在使用的通用案例。

网站的运营管理:

这里为了脱敏显示,针对的是日常的Wordpress网站运营,基于日志实时解析网站动态,深度分析访问流量趋势、用户行为特征,结合风险库自动封禁恶意地址,以下为主要的能力:

网站访问热力分析:实时解析Nginx访问日志,统计PV、UV及地域分布,输出ECharts流量趋势与热力图洞察。
IP安全风险画像:基于Nginx日志智能识别高频请求、恶意扫描IP,结合黑白名单策略生成风险管控报告。
站点性能监控日报:聚合Nginx响应码与响应时长数据,统计可用性指标,自动输出图文并茂的站点健康报告。

项目管理及周日报:

项目进度情况分析还有团队风险管理分析,SKILL集成的是禅道、阿里云效、还有代码版本管理器。

阶段复盘:复盘节点进度、排查滞后问题,紧盯交付节奏不跑偏
风险预警:识别团队协作、人力等隐患,制定预案降低执行风险
决策汇报:呈现客观数据与风险结论,为管理层、甲方提供决策依据

系统管理日常运维:

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

K8s集群健康度诊断:自动聚合集群节点与应用日志,智能识别异常状态,输出多维度的健康评分与趋势图表。
服务器资源全景监控:整合多地域物理机与虚拟机指标,实时统计CPU、内存利用率,生成可视化资源拓扑图。
运维故障智能溯源:关联K8S事件与服务器日志,快速定位根因,输出图文并茂的故障分析报告。

数据分析及治理:

结合上传的Excel进行图表化分析,SKIL集成的是Excel操作还有图表的操作,合并、统计、清晰等整理材料。

销售季度复盘分析:自动合并多区域销售Excel,清洗杂乱数据并统计核心指标,生成带ECharts趋势图的可视化复盘报告。
学生成绩诊断报告:整合多次考试成绩,智能去重与计算班级均分、进退步,输出图文并茂的学情分析图表。
电商运营日报生成:定时汇总多渠道订单Excel,清洗无效数据后统计GMV、退款率,并自动生成可视化运营仪表盘。

工具库

单独抽取成了工具平台,给Agent提供能力,SKILL+MCP+插件+客户端Socket管理+Sanbox管理。

更多的是体现Claw版本的综合能力,还有线上线下的集成示例,在这个过程中,集成了很多实用性的SKILL能力,而且这些都是集成做过验证的场景,可以根据自身的需求做调整。

然后提供的多本地Claw管理,这里采用websocket连接的方式集成。

总结

以上为当前对AIP版Claw的整体产品设计,结合了本身OpenClaw本身化的优点,同时也结合了前期类ManusAI的产品设计思路,结合线上与线下的版本。

每个技术研究不一样,期望给一些有兴趣朋友一些参考。