1. 为什么“先建工作空间”是AI原生运维的第一性原理1.1 从一个真实的翻车现场说起去年我接手了一个中等规模的微服务集群大概四十多个服务跑在三个环境里。当时团队想搞“智能化运维”第一反应就是接个大模型进来让它帮忙看日志、分析告警。我们花了大概两周时间把日志接口、监控接口、告警接口全部对接给模型做了一个看起来挺像样的对话入口。结果上线第三天就出事了——一个核心支付服务开始间歇性超时模型给出的分析是“建议重启该服务”值班同学照做了重启完确实好了十分钟然后继续超时。后来人工排查发现根因是下游一个不起眼的配置中心连接池被打满了重启支付服务只是暂时释放了连接根本没解决问题。这件事让我彻底想明白一个道理AI原生运维不是把大模型接到运维系统上就完事了而是要让AI像人一样对每个系统有“上下文感知能力”。人为什么能排查出根因因为老运维脑子里有一张图——他知道支付服务依赖配置中心知道配置中心的连接池参数是多少知道最近有没有人改过配置。而当时的AI看到的只是孤立的日志和指标它没有“工作空间”这个概念自然给不出靠谱的判断。所以标题里说的“先给每个系统建一个工作空间”本质上是在解决AI运维的上下文缺失问题。工作空间就是AI的“工位”在这个工位里它能看到这个系统所有相关的信息代码仓库、部署配置、监控面板、历史告警、变更记录、依赖关系。没有这个工位AI就是个到处乱逛的临时工今天看看这个日志明天查查那个指标永远建立不起对系统的整体认知。1.2 工作空间到底装了什么很多人第一次听到“工作空间”这个词会以为就是建个文件夹把文档丢进去。不是的。一个合格的AI运维工作空间至少包含五类信息我把它叫做“五件套”静态资产这个系统的代码仓库地址、镜像仓库地址、部署清单Kubernetes YAML或者Helm Chart、配置文件模板。这些东西让AI知道“这个系统长什么样”。动态指标Prometheus或者同类监控系统里这个系统相关的所有指标包括CPU、内存、QPS、延迟、错误率以及自定义的业务指标。这是AI的“体检数据”。日志与事件这个系统产生的日志流、Kubernetes事件、变更审计日志。这是AI的“病历本”。依赖拓扑这个系统依赖了谁、被谁依赖、中间件是谁、数据库是谁。这是AI的“关系网”。操作历史最近谁做了什么变更、什么时候发的版、回滚过几次。这是AI的“记忆”。这五类信息缺一不可。我见过有些团队只给AI接监控指标结果AI看到CPU高了就喊扩容完全不知道是因为上游突然来了流量高峰扩完容流量一过又浪费资源。也见过只给AI接日志的AI能从日志里看出报错但不知道这个报错对应的服务版本是哪个给出的修复建议驴唇不对马嘴。提示工作空间的信息不是越多越好而是要“全而准”。我建议初期先覆盖核心系统每个系统的五件套必须完整宁可少接几个系统也不要接一堆信息残缺的系统。信息残缺的工作空间比没有工作空间更危险因为AI会基于不完整的信息给出看似合理实则错误的判断。1.3 AI原生运维和传统AIOps的根本区别这里需要厘清一个概念。传统AIOps智能运维的核心是“算法找规律”比如用时间序列异常检测算法发现指标异常用聚类算法把相似告警归并用根因分析算法定位故障点。这些算法的共同特点是它们不需要理解系统只需要理解数据。AI原生运维不一样。它的核心是“Agent理解系统”。Agent智能体不是被动地等数据喂进来而是主动地去工作空间里探索。比如你问它“支付服务为什么变慢了”它会自己去查支付服务的监控指标、去看最近的变更记录、去对比上下游服务的延迟变化、去翻日志里的异常堆栈。这个过程和人排查问题的思路是一样的。打个比方传统AIOps像是一个只会看仪表盘的司机仪表盘亮红灯他就报警AI原生运维像是一个有经验的修车师傅他不仅看仪表盘还会打开引擎盖听声音、闻气味、摸温度综合判断问题出在哪。这就是为什么“工作空间”是AI原生运维的基石。没有工作空间Agent就没有探索的空间只能退化成传统AIOps的算法调用器。有了工作空间Agent才能真正发挥它的推理能力。1.4 适合谁来参考这套思路这套思路适合三类人第一类是运维工程师尤其是正在被“告警风暴”折磨的SRE。如果你每天要处理几百条告警其中大部分是噪音那工作空间Agent的方案能帮你把噪音过滤掉让AI先做一轮初筛。第二类是平台工程师正在建设内部运维平台或者DevOps平台。工作空间可以作为平台的核心抽象把散落在各个工具里的信息聚合起来不仅给AI用也给人用。第三类是AI应用开发者想切入运维场景但不知道从哪下手。工作空间是一个很好的切入点它比做通用Agent简单因为运维领域的边界相对清晰信息源也相对标准化。不管你属于哪一类我的建议都是不要一上来就追求全自动。先建工作空间让AI能回答问题再逐步让它能执行操作。步子迈大了容易扯着蛋这是我踩过坑之后的真心话。2. 工作空间的核心架构与关键设计决策2.1 工作空间的数据模型怎么设计建工作空间的第一步是设计数据模型。我试过三种方案最后选了一种最“笨”但最稳的。第一种方案是“大宽表”把所有信息塞进一个Elasticsearch索引里字段随便加。这种方案上手快但很快就会出现字段爆炸、查询性能下降、数据一致性差的问题。我试过在一个索引里塞了三百多个字段后来连自己都记不清哪个字段是干什么的。第二种方案是“图数据库”用Neo4j把系统、服务、依赖、告警都建成节点和边。这种方案查询关系很爽但写入和维护成本高而且大部分运维场景其实不需要那么复杂的图查询。第三种方案是我最终采用的分层存储统一标识。具体来说资产层用关系型数据库PostgreSQL就行存系统元数据、依赖关系、负责人信息。这部分数据量小但要求强一致。指标层用时序数据库Prometheus或者VictoriaMetrics存监控指标。这部分数据量大但写入模式简单。日志层用日志系统Loki或者Elasticsearch存日志和事件。这部分要求全文检索能力。向量层用向量数据库比如Milvus或者Qdrant存文档、历史工单、变更记录的向量化表示。这部分给Agent做语义检索用。四层之间用一个统一的“系统标识”串起来。这个标识我建议用“环境-系统名-实例ID”的三段式比如prod-payment-service-001。所有层的数据都带上这个标识Agent查询的时候先拿到标识再去各层拉数据。注意统一标识看起来简单但实际落地时最容易出问题。我见过很多团队监控系统里叫payment日志系统里叫payment-serviceCMDB里叫支付服务Agent一查就懵了。建议在建工作空间之前先花一周时间把命名规范统一了磨刀不误砍柴工。2.2 Agent在工作空间里怎么“干活”工作空间建好了接下来要让Agent在里面干活。这里的关键是设计好Agent的“工具集”。Agent不是直接访问数据库的而是通过工具来操作。我一般给Agent配这几类工具查询类工具查指标、查日志、查依赖、查变更记录。这类工具是只读的Agent可以随便调不用担心搞出问题。分析类工具异常检测、趋势预测、相关性分析。这类工具封装了一些算法Agent不需要自己算直接调就行。操作类工具重启服务、扩容、回滚、修改配置。这类工具是写操作必须加审批或者二次确认。我的做法是初期全部禁用等Agent的准确率上来了再逐步开放。协作类工具创建工单、通知负责人、拉群。这类工具让Agent能和人协作而不是自己闷头干。工具集的设计原则是查询类要丰富分析类要精准操作类要克制。我见过有团队一上来就给Agent开放了重启权限结果Agent因为一个误判把生产环境的核心服务重启了虽然没造成大事故但把大家吓出一身冷汗。Agent调用工具的流程一般是这样的先理解用户的问题然后规划需要调哪些工具接着按顺序调用最后综合结果给出回答。这个过程和人在工作空间里排查问题是一模一样的。2.3 为什么不用“一个大Agent管所有系统”这是我在架构设计上纠结最久的一个问题。最初的方案是做一个“全能Agent”它能看到所有系统的工作空间用户问什么它查什么。听起来很美好但实际跑起来问题很多。第一个问题是上下文爆炸。四十多个系统的信息全塞给Agent光是系统列表就占了几千个token真正有用的信息反而被淹没了。Agent经常答非所问因为它被无关信息干扰了。第二个问题是权限混乱。不同系统有不同的负责人和权限要求一个大Agent很难做到精细化的权限控制。你不想让一个实习生通过Agent查到核心支付系统的敏感配置吧第三个问题是准确率下降。我做过对比测试同样的问题用“全能Agent”的准确率是62%用“每个系统一个专属Agent”的准确率是89%。差距非常明显。所以我的建议是每个系统建一个工作空间每个工作空间配一个专属Agent。用户提问时先路由到对应系统的Agent再由这个Agent在工作空间里干活。如果问题涉及多个系统就由多个Agent协作或者由一个“协调Agent”来调度。这个架构的好处是每个Agent的上下文是干净的权限是清晰的准确率也高。坏处是Agent数量多了之后管理成本上升但这个问题可以通过模板化来解决——大部分Agent的配置是相似的只有工具集和知识库不同。2.4 工作空间的“冷启动”怎么做新建一个工作空间最怕的是“空荡荡”。Agent进去一看什么信息都没有问它问题它也说不知道。所以工作空间的冷启动很重要。我的做法是分三步走第一步自动发现。写一个采集器从现有的监控系统、日志系统、CMDB、代码仓库里自动拉取信息填充工作空间的基础数据。这一步能解决80%的信息填充问题。第二步人工补全。自动发现拿不到的信息比如系统的业务含义、关键联系人、特殊注意事项需要人工补。我一般会做一个简单的表单让系统负责人花十分钟填一下。别小看这十分钟它能让Agent的回答质量提升一个档次。第三步历史沉淀。把过去半年的告警记录、工单记录、变更记录导入工作空间让Agent有“历史经验”可以参考。这一步是长期工程可以边用边补。冷启动做完之后工作空间就算“活”了。但要注意工作空间不是建完就不管了它需要持续更新。我的做法是每天自动同步一次基础数据每周人工review一次知识库每月做一次全面盘点。3. 从零搭建一个AI运维工作空间的完整实操3.1 环境准备与基础组件选型假设你现在要从零开始搭一套我把我用过的组件清单列一下都是经过生产验证的不是随便找的。组件类型推荐选型备选方案选择理由关系型数据库PostgreSQL 15MySQL 8JSON字段支持好适合存半结构化的资产数据时序数据库VictoriaMetricsPrometheus单机性能强运维简单兼容PromQL日志系统LokiElasticsearch资源占用低和Grafana集成好向量数据库QdrantMilvus部署简单API友好适合中小规模Agent框架LangChainLlamaIndex工具调用生态成熟社区活跃大模型本地部署开源模型商用API数据不出内网成本可控编排层自研轻量调度器Airflow运维场景不需要那么重的编排选型的原则是能用单机就不用集群能用开源就不用商业能本地部署就不上云。运维数据敏感而且量级通常没有互联网业务那么大单机方案足够撑住。环境准备的具体步骤# 以Ubuntu 22.04为例安装Docker和Docker Compose sudo apt update sudo apt install -y docker.io docker-compose-plugin # 创建数据目录 sudo mkdir -p /data/aiops/{postgres,victoria,loki,qdrant} sudo chown -R $USER:$USER /data/aiops # 启动基础组件docker-compose.yml片段version: 3.8 services: postgres: image: postgres:15 volumes: - /data/aiops/postgres:/var/lib/postgresql/data environment: POSTGRES_PASSWORD: your_password ports: - 5432:5432 victoria: image: victoriametrics/victoria-metrics:latest volumes: - /data/aiops/victoria:/victoria-metrics-data ports: - 8428:8428 qdrant: image: qdrant/qdrant:latest volumes: - /data/aiops/qdrant:/qdrant/storage ports: - 6333:6333这套环境在一台16核64G的机器上跑支撑五十个系统的工作空间没问题。如果系统数量更多可以把时序数据库和向量数据库拆出去单独部署。提示大模型的选择很关键。我试过用7B参数的模型做Agent工具调用的准确率只有70%左右经常调错工具或者参数传错。后来换成14B以上的模型准确率提升到90%以上。如果条件允许建议至少用14B的模型量化后的版本在24G显存的卡上能跑。3.2 工作空间元数据的建模与录入环境准备好之后开始建数据模型。我在PostgreSQL里建了这几张核心表-- 系统表 CREATE TABLE systems ( id SERIAL PRIMARY KEY, sys_key VARCHAR(128) UNIQUE NOT NULL, -- 统一标识如 prod-payment-service name VARCHAR(256) NOT NULL, env VARCHAR(32) NOT NULL, -- prod/staging/dev owner VARCHAR(128), description TEXT, created_at TIMESTAMP DEFAULT NOW() ); -- 依赖关系表 CREATE TABLE dependencies ( id SERIAL PRIMARY KEY, from_sys VARCHAR(128) NOT NULL, to_sys VARCHAR(128) NOT NULL, dep_type VARCHAR(64), -- rpc/db/cache/mq critical BOOLEAN DEFAULT FALSE, UNIQUE(from_sys, to_sys, dep_type) ); -- 资产表 CREATE TABLE assets ( id SERIAL PRIMARY KEY, sys_key VARCHAR(128) NOT NULL, asset_type VARCHAR(64), -- repo/image/config/dashboard asset_uri TEXT NOT NULL, extra JSONB, UNIQUE(sys_key, asset_type, asset_uri) ); -- 知识条目表 CREATE TABLE knowledge ( id SERIAL PRIMARY KEY, sys_key VARCHAR(128) NOT NULL, category VARCHAR(64), -- faq/runbook/incident title VARCHAR(512), content TEXT, embedding_id VARCHAR(128), -- 对应向量库里的ID created_at TIMESTAMP DEFAULT NOW() );建完表之后写一个采集脚本从现有系统里拉数据。我一般用Python写因为运维同学对Python最熟悉。import psycopg2 import requests def sync_systems_from_cmdb(): 从CMDB同步系统列表 resp requests.get(http://cmdb.internal/api/systems) systems resp.json() conn psycopg2.connect(dbnameaiops userpostgres passwordyour_password hostlocalhost) cur conn.cursor() for sys in systems: cur.execute( INSERT INTO systems (sys_key, name, env, owner, description) VALUES (%s, %s, %s, %s, %s) ON CONFLICT (sys_key) DO UPDATE SET name EXCLUDED.name, owner EXCLUDED.owner, description EXCLUDED.description , (sys[key], sys[name], sys[env], sys[owner], sys[desc])) conn.commit() cur.close() conn.close()这个脚本每天跑一次保证工作空间的元数据是最新的。依赖关系可以从服务网格或者调用链系统里拉资产信息可以从代码仓库和镜像仓库的API拉。录入的时候有个坑要注意不要一次性把所有系统都录进来。我建议先选三到五个核心系统做试点跑通了再逐步扩展。一次性全录进来数据质量问题会把你淹没而且Agent的表现不好你也找不到原因。3.3 Agent工具集的具体实现工具集是Agent和工作空间之间的桥梁。我用LangChain的Tool抽象来实现每个工具就是一个Python函数。from langchain.tools import tool import requests tool def query_metrics(sys_key: str, metric: str, duration: str 1h) - str: 查询指定系统的监控指标。 Args: sys_key: 系统标识如 prod-payment-service metric: 指标名称如 cpu_usage, qps, latency_p99 duration: 查询时间范围如 1h, 6h, 24h # 调用VictoriaMetrics的PromQL接口 query f{metric}{{sys{sys_key}}} resp requests.get( http://localhost:8428/api/v1/query_range, params{query: query, start: f-{duration}, step: 60s} ) data resp.json() # 简化返回只给Agent关键信息 values data[data][result][0][values] if data[data][result] else [] if not values: return f未查询到 {sys_key} 的 {metric} 指标数据 latest values[-1][1] max_val max(float(v[1]) for v in values) avg_val sum(float(v[1]) for v in values) / len(values) return f{sys_key} 的 {metric}当前值 {latest}最大值 {max_val:.2f}平均值 {avg_val:.2f} tool def query_logs(sys_key: str, keyword: str, duration: str 1h) - str: 查询指定系统的日志。 Args: sys_key: 系统标识 keyword: 搜索关键词如 error, timeout, exception duration: 查询时间范围 # 调用Loki的查询接口 end int(time.time() * 1e9) start end - parse_duration(duration) query f{{sys{sys_key}}} | {keyword} resp requests.get( http://localhost:3100/loki/api/v1/query_range, params{query: query, start: start, end: end, limit: 50} ) # 返回日志摘要 ... tool def query_dependencies(sys_key: str) - str: 查询指定系统的依赖关系。 conn psycopg2.connect(...) cur conn.cursor() cur.execute(SELECT to_sys, dep_type, critical FROM dependencies WHERE from_sys %s, (sys_key,)) deps cur.fetchall() cur.execute(SELECT from_sys, dep_type FROM dependencies WHERE to_sys %s, (sys_key,)) upstream cur.fetchall() ... return f下游依赖{deps}上游调用方{upstream} tool def query_changes(sys_key: str, duration: str 24h) - str: 查询指定系统最近的变更记录。 ...工具实现有几个要点第一返回值要精简。Agent的上下文窗口有限工具返回一大堆原始数据反而会干扰它。我一般只返回关键统计值和少量样本比如“最大值、平均值、当前值”和“最近三条错误日志”。第二参数要少而明确。工具的参数越多Agent调错的概率越大。我尽量把参数控制在三个以内而且参数名要直白比如sys_key、metric、duration。第三错误处理要友好。工具调用失败时不要抛异常而是返回一个描述性的错误信息让Agent知道发生了什么。比如“未查询到数据”比“KeyError”对Agent友好得多。第四工具描述要详细。LangChain的工具描述会作为prompt的一部分传给模型描述写得越清楚模型调用得越准确。我一般会在描述里写清楚参数的含义、格式、示例。3.4 把工作空间和Agent串起来工具写好了接下来要把它们和Agent串起来。我用的是LangChain的AgentExecutor配置如下from langchain.agents import AgentExecutor, create_openai_tools_agent from langchain.prompts import ChatPromptTemplate # 系统提示词这是Agent的“人设” SYSTEM_PROMPT 你是一个专业的运维助手负责帮助工程师排查 {sys_key} 系统的问题。 你可以使用以下工具来获取信息 - query_metrics: 查询监控指标 - query_logs: 查询日志 - query_dependencies: 查询依赖关系 - query_changes: 查询变更记录 工作原则 1. 先理解问题再规划需要查什么信息 2. 查询信息时优先查最近1小时的数据 3. 给出结论时必须基于查询到的实际数据不要臆测 4. 如果信息不足明确告诉用户还需要什么信息 5. 涉及操作类建议时必须提醒用户人工确认 当前系统{sys_key} 系统描述{sys_desc} prompt ChatPromptTemplate.from_messages([ (system, SYSTEM_PROMPT), (human, {input}), (placeholder, {agent_scratchpad}), ]) # 为每个系统创建一个Agent实例 def create_system_agent(sys_key, sys_desc, tools): agent create_openai_tools_agent(llm, tools, prompt) return AgentExecutor( agentagent, toolstools, verboseTrue, max_iterations10, # 防止Agent陷入死循环 handle_parsing_errorsTrue, ) # 路由层根据用户问题找到对应的系统 def route_question(question): # 简单实现用关键词匹配 for sys_key in all_systems: if sys_key in question or all_systems[sys_key][name] in question: return sys_key # 复杂实现用一个小模型做意图分类 return classify_intent(question)这里有几个实操心得max_iterations一定要设。我试过不设限制Agent有时候会陷入“查了指标觉得不够又去查日志查完日志觉得不够又去查指标”的死循环烧了一堆token还没给出答案。设成10次一般够用。verbose模式在调试时开生产时关。verbose会把Agent的每一步思考都打出来调试的时候很有用但生产环境日志量太大。路由层是必须的。不要让用户手动指定系统那样体验太差。用关键词匹配做第一版就行准确率不够再上模型分类。每个系统的Agent要独立配置。不同系统的工具集可能不一样比如有的系统没有配置中心那就不需要查配置的工具。独立配置能让Agent更专注。3.5 一个完整的排查案例演示说了这么多理论来看一个实际案例。用户问“支付服务今天下午开始变慢了帮我看看什么原因。”路由层识别出sys_key prod-payment-service把问题转给支付服务的Agent。Agent的思考过程简化版第一步调用query_metrics查延迟指标query_metrics(sys_keyprod-payment-service, metriclatency_p99, duration6h)返回当前值 1250ms最大值 1800ms平均值 320ms。说明下午确实有延迟飙升。第二步调用query_metrics查QPSquery_metrics(sys_keyprod-payment-service, metricqps, duration6h)返回当前值 1200最大值 1250平均值 1180。QPS没有明显变化排除流量突增。第三步调用query_dependencies查依赖query_dependencies(sys_keyprod-payment-service)返回下游依赖 config-center配置中心、mysql-main、redis-cache。第四步调用query_metrics查下游依赖的延迟query_metrics(sys_keyconfig-center, metriclatency_p99, duration6h)返回config-center 的延迟从下午2点开始从 5ms 飙升到 800ms。第五步调用query_changes查配置中心的变更query_changes(sys_keyconfig-center, duration24h)返回下午1点50分有人修改了配置中心的连接池大小从 200 改成了 20。Agent综合以上信息给出结论“支付服务变慢的根因是配置中心在下午1点50分进行了变更连接池从200缩小到20导致配置读取延迟飙升进而拖慢了支付服务。建议回滚该变更或调大连接池。”整个过程Agent调用了五次工具耗时约15秒。如果人工排查至少需要20分钟。这就是工作空间Agent的价值。注意这个案例里Agent能定位到根因关键在于工作空间里有完整的依赖关系和变更记录。如果只接了监控指标Agent最多只能告诉你“支付服务变慢了配置中心也变慢了”但没法建立因果关系。所以再强调一遍五件套要完整。4. 落地过程中最容易踩的坑与排查手册4.1 Agent答非所问的五个常见原因这是最常见的问题。你问AAgent答B或者答得云里雾里。我总结了五个原因和对应的解法现象可能原因排查方法解决方案Agent调用工具时参数传错工具描述不清晰看verbose日志里Agent传的参数完善工具描述加参数示例Agent查了无关的系统路由层匹配错误检查路由层的匹配逻辑改用模型做意图分类Agent给出臆测的结论系统提示词约束不够看Agent是否基于实际数据回答在提示词里强调“必须基于数据”Agent反复查同一个工具max_iterations没设或太大看日志里工具调用次数设max_iterations10加去重逻辑Agent回答太啰嗦提示词没有输出格式要求看回答长度在提示词里规定输出格式和字数我重点说一下“Agent给出臆测结论”这个问题。大模型有个毛病就是它倾向于给出一个“看起来合理”的答案哪怕它没有足够的信息。在运维场景里这很危险因为一个错误的结论可能导致错误的操作。我的解法是在系统提示词里加一条硬约束“如果你没有查询到相关数据必须明确说‘未查询到数据无法判断’禁止基于常识或经验给出推测性结论。”这条约束加上之后Agent的“幻觉率”明显下降。另外我还会在Agent给出结论后做一个“事实校验”把Agent的结论和它查询到的数据做比对如果结论里提到的数字在查询结果里找不到就标记为可疑。这个校验可以用简单的字符串匹配实现不需要模型。4.2 工作空间数据不同步的排查思路工作空间的数据来自多个系统不同步是常态。我遇到过这几种情况监控指标延迟。Prometheus默认15秒抓一次VictoriaMetrics可能有额外的写入延迟。如果Agent查的是最近1分钟的数据可能查不到。解法是在工具里把查询时间范围往前推5分钟或者明确告诉Agent“最近5分钟的数据可能不完整”。日志采集延迟。Loki的采集链路是Promtail - Loki中间可能有几十秒的延迟。如果Agent查“刚刚发生的错误”可能查不到。解法是让Agent查“最近5分钟”而不是“最近1分钟”。CMDB更新延迟。CMDB的数据往往是人工维护的更新不及时。如果新上线的服务没录入CMDBAgent就查不到。解法是做一个自动发现机制从Kubernetes的API里自动同步服务列表和CMDB做比对发现差异就告警。依赖关系过期。服务之间的依赖关系是动态变化的今天A依赖B明天可能就不依赖了。如果依赖关系没更新Agent的分析就会出错。解法是定期从服务网格或者调用链系统里重新拉取依赖关系每周更新一次。排查数据不同步的问题我的经验是先看数据源再看采集链路最后看工作空间。大部分问题出在数据源本身而不是工作空间。4.3 权限与安全的红线怎么划AI运维涉及生产系统权限和安全是红线。我的做法是“三层隔离”第一层网络隔离。工作空间的各个组件部署在内网不暴露公网。Agent访问工具走内网API不走公网。第二层数据隔离。不同系统的工作空间数据在逻辑上隔离Agent只能访问自己系统的数据。敏感数据如数据库密码、密钥不进入工作空间Agent查询时返回脱敏后的结果。第三层操作隔离。查询类工具直接开放分析类工具记录审计日志操作类工具必须人工审批。我一般会做一个审批流Agent提出操作建议推送给系统负责人负责人确认后才执行。提示不要给Agent开放“删除”类操作哪怕是测试环境。我见过一个案例Agent在测试环境误删了一个数据库虽然可以恢复但浪费了半天时间。删除操作永远应该由人来做。另外Agent的对话记录要保存至少保存半年。这不仅是审计要求也是改进Agent的依据。我每周会抽看一些对话记录看看Agent哪些问题答得好哪些答得不好然后针对性地优化提示词和工具。4.4 成本控制的实操经验大模型调用是有成本的尤其是用商用API的时候。我算过一笔账一个中等规模的集群每天大概有200次Agent调用每次调用平均消耗3000个token包括系统提示词、工具调用、工具返回、最终回答一天就是60万token。如果用商用API一天的成本大概在几十到几百元不等。控制成本有几个办法第一缓存常用查询。有些查询是重复的比如“支付服务的QPS是多少”可能一天被问十几次。我加了一层缓存同样的查询5分钟内直接返回缓存结果不调模型。第二精简系统提示词。系统提示词每次调用都要传如果写得太长成本会很高。我一般控制在500字以内只保留最关键的约束。第三工具返回精简。前面说过工具返回的数据要精简这不仅是为了Agent的准确率也是为了省token。返回一堆原始数据token消耗会翻好几倍。第四用本地模型做初筛。简单的查询比如“查一下CPU使用率”用本地的小模型处理复杂的分析才用大模型。这样能省不少钱。第五设置每日限额。给每个系统设一个每日token限额超了就停止服务第二天恢复。这能防止异常调用把预算烧光。我实测下来用本地部署的14B模型一台24G显存的机器每天处理500次调用没问题成本就是电费。如果预算有限建议优先考虑本地部署。4.5 常见问题速查表最后整理一份速查表都是我实际遇到过的问题问题排查步骤解决方案Agent不调用工具直接回答检查工具是否注册成功确认tools列表非空检查工具描述Agent调用工具报错看verbose日志里的错误信息检查工具函数的参数类型和返回值Agent回答超时看max_iterations和工具耗时减少max_iterations优化工具查询性能工作空间查不到数据检查数据源和采集链路确认数据已写入检查查询语句Agent回答不准确检查工作空间数据完整性补全五件套完善系统提示词模型响应慢检查模型部署的硬件资源升级GPU或换用更小的量化模型多个系统问题混淆检查路由层匹配逻辑改用模型做意图分类加系统隔离这份表我贴在工位上遇到问题先查表能解决80%的常见问题。剩下的20%需要具体分析但有了这份表至少不会像无头苍蝇一样乱撞。5. 工作空间的扩展方向与长期演进5.1 从单系统到多系统协作单个系统的工作空间跑通之后下一步自然是多系统协作。比如用户问“支付服务变慢是不是因为订单服务的问题”这就需要两个系统的Agent协作。我的做法是引入一个“协调Agent”它不直接查数据而是负责调度。协调Agent收到问题后先拆解成子问题分发给对应的系统Agent收集结果后再综合。协调Agent的实现比系统Agent简单它不需要工具集只需要一个“分发”工具和一个“汇总”工具。但难点在于子问题的拆解和结果的融合这需要比较强的推理能力建议用大一点的模型。多系统协作的典型场景包括跨系统的故障排查、容量规划、变更影响分析。这些场景单系统Agent搞不定必须多Agent协作。5.2 从被动问答到主动巡检现在的工作空间是“被动”的用户问什么它答什么。下一步是让它“主动”起来定期巡检发现问题主动告警。主动巡检的实现方式是给每个系统的工作空间配一个定时任务每隔一段时间比如5分钟自动跑一遍检查项包括核心指标是否异常、是否有新的错误日志、是否有未预期的变更。发现异常就推送给负责人。主动巡检的关键是“降噪”。如果巡检太频繁告警太多大家就会麻木。我的做法是只对“确认异常”的情况告警疑似异常先记录不告警。确认异常的判断可以用规则模型结合的方式规则做初筛模型做确认。5.3 从运维场景到研发场景的延伸工作空间的思路不仅适用于运维也适用于研发。比如给每个代码仓库建一个工作空间把代码、CI/CD流水线、测试报告、代码评审记录都放进去配一个Agent帮开发者查问题。我试过在代码评审场景用这个思路Agent自动检查代码变更是否影响了依赖的系统是否有对应的测试覆盖是否有性能风险。效果不错能帮评审人省不少时间。研发场景的工作空间和运维场景的工作空间底层架构是一样的只是数据源和工具集不同。所以前期投入建工作空间的成本可以在多个场景复用这是很划算的。5.4 我个人的一些体会做AI原生运维这一年多我最大的体会是技术不是瓶颈数据才是。大模型的能力已经足够强了Agent框架也很成熟真正难的是把数据整理好、把工作空间建好。我见过太多团队模型选型纠结了两个月工作空间的数据却乱七八糟最后做出来的东西没法用。另一个体会是不要追求全自动。AI运维的目标不是取代人而是帮人省时间。Agent能帮你把排查时间从20分钟缩短到2分钟这就很好了。剩下的2分钟让人来做决策这样既高效又安全。最后一个体会是从小处着手。不要一上来就搞大平台先选一个系统建一个工作空间配一个Agent跑通一个场景。跑通之后再复制到其他系统。我见过太多“大平台”项目做了一年还在开发而小步快跑的项目已经上线半年了。这个方向后续还可以扩展很多比如把工作空间和混沌工程结合让Agent在故障演练中学习比如把工作空间和容量管理结合让Agent做资源预测。但这些都是后话先把基础的工作空间建好把五件套填满把Agent调准比什么都重要。 AI原生运维实战：先建工作空间，再谈智能体
1. 为什么“先建工作空间”是AI原生运维的第一性原理1.1 从一个真实的翻车现场说起去年我接手了一个中等规模的微服务集群大概四十多个服务跑在三个环境里。当时团队想搞“智能化运维”第一反应就是接个大模型进来让它帮忙看日志、分析告警。我们花了大概两周时间把日志接口、监控接口、告警接口全部对接给模型做了一个看起来挺像样的对话入口。结果上线第三天就出事了——一个核心支付服务开始间歇性超时模型给出的分析是“建议重启该服务”值班同学照做了重启完确实好了十分钟然后继续超时。后来人工排查发现根因是下游一个不起眼的配置中心连接池被打满了重启支付服务只是暂时释放了连接根本没解决问题。这件事让我彻底想明白一个道理AI原生运维不是把大模型接到运维系统上就完事了而是要让AI像人一样对每个系统有“上下文感知能力”。人为什么能排查出根因因为老运维脑子里有一张图——他知道支付服务依赖配置中心知道配置中心的连接池参数是多少知道最近有没有人改过配置。而当时的AI看到的只是孤立的日志和指标它没有“工作空间”这个概念自然给不出靠谱的判断。所以标题里说的“先给每个系统建一个工作空间”本质上是在解决AI运维的上下文缺失问题。工作空间就是AI的“工位”在这个工位里它能看到这个系统所有相关的信息代码仓库、部署配置、监控面板、历史告警、变更记录、依赖关系。没有这个工位AI就是个到处乱逛的临时工今天看看这个日志明天查查那个指标永远建立不起对系统的整体认知。1.2 工作空间到底装了什么很多人第一次听到“工作空间”这个词会以为就是建个文件夹把文档丢进去。不是的。一个合格的AI运维工作空间至少包含五类信息我把它叫做“五件套”静态资产这个系统的代码仓库地址、镜像仓库地址、部署清单Kubernetes YAML或者Helm Chart、配置文件模板。这些东西让AI知道“这个系统长什么样”。动态指标Prometheus或者同类监控系统里这个系统相关的所有指标包括CPU、内存、QPS、延迟、错误率以及自定义的业务指标。这是AI的“体检数据”。日志与事件这个系统产生的日志流、Kubernetes事件、变更审计日志。这是AI的“病历本”。依赖拓扑这个系统依赖了谁、被谁依赖、中间件是谁、数据库是谁。这是AI的“关系网”。操作历史最近谁做了什么变更、什么时候发的版、回滚过几次。这是AI的“记忆”。这五类信息缺一不可。我见过有些团队只给AI接监控指标结果AI看到CPU高了就喊扩容完全不知道是因为上游突然来了流量高峰扩完容流量一过又浪费资源。也见过只给AI接日志的AI能从日志里看出报错但不知道这个报错对应的服务版本是哪个给出的修复建议驴唇不对马嘴。提示工作空间的信息不是越多越好而是要“全而准”。我建议初期先覆盖核心系统每个系统的五件套必须完整宁可少接几个系统也不要接一堆信息残缺的系统。信息残缺的工作空间比没有工作空间更危险因为AI会基于不完整的信息给出看似合理实则错误的判断。1.3 AI原生运维和传统AIOps的根本区别这里需要厘清一个概念。传统AIOps智能运维的核心是“算法找规律”比如用时间序列异常检测算法发现指标异常用聚类算法把相似告警归并用根因分析算法定位故障点。这些算法的共同特点是它们不需要理解系统只需要理解数据。AI原生运维不一样。它的核心是“Agent理解系统”。Agent智能体不是被动地等数据喂进来而是主动地去工作空间里探索。比如你问它“支付服务为什么变慢了”它会自己去查支付服务的监控指标、去看最近的变更记录、去对比上下游服务的延迟变化、去翻日志里的异常堆栈。这个过程和人排查问题的思路是一样的。打个比方传统AIOps像是一个只会看仪表盘的司机仪表盘亮红灯他就报警AI原生运维像是一个有经验的修车师傅他不仅看仪表盘还会打开引擎盖听声音、闻气味、摸温度综合判断问题出在哪。这就是为什么“工作空间”是AI原生运维的基石。没有工作空间Agent就没有探索的空间只能退化成传统AIOps的算法调用器。有了工作空间Agent才能真正发挥它的推理能力。1.4 适合谁来参考这套思路这套思路适合三类人第一类是运维工程师尤其是正在被“告警风暴”折磨的SRE。如果你每天要处理几百条告警其中大部分是噪音那工作空间Agent的方案能帮你把噪音过滤掉让AI先做一轮初筛。第二类是平台工程师正在建设内部运维平台或者DevOps平台。工作空间可以作为平台的核心抽象把散落在各个工具里的信息聚合起来不仅给AI用也给人用。第三类是AI应用开发者想切入运维场景但不知道从哪下手。工作空间是一个很好的切入点它比做通用Agent简单因为运维领域的边界相对清晰信息源也相对标准化。不管你属于哪一类我的建议都是不要一上来就追求全自动。先建工作空间让AI能回答问题再逐步让它能执行操作。步子迈大了容易扯着蛋这是我踩过坑之后的真心话。2. 工作空间的核心架构与关键设计决策2.1 工作空间的数据模型怎么设计建工作空间的第一步是设计数据模型。我试过三种方案最后选了一种最“笨”但最稳的。第一种方案是“大宽表”把所有信息塞进一个Elasticsearch索引里字段随便加。这种方案上手快但很快就会出现字段爆炸、查询性能下降、数据一致性差的问题。我试过在一个索引里塞了三百多个字段后来连自己都记不清哪个字段是干什么的。第二种方案是“图数据库”用Neo4j把系统、服务、依赖、告警都建成节点和边。这种方案查询关系很爽但写入和维护成本高而且大部分运维场景其实不需要那么复杂的图查询。第三种方案是我最终采用的分层存储统一标识。具体来说资产层用关系型数据库PostgreSQL就行存系统元数据、依赖关系、负责人信息。这部分数据量小但要求强一致。指标层用时序数据库Prometheus或者VictoriaMetrics存监控指标。这部分数据量大但写入模式简单。日志层用日志系统Loki或者Elasticsearch存日志和事件。这部分要求全文检索能力。向量层用向量数据库比如Milvus或者Qdrant存文档、历史工单、变更记录的向量化表示。这部分给Agent做语义检索用。四层之间用一个统一的“系统标识”串起来。这个标识我建议用“环境-系统名-实例ID”的三段式比如prod-payment-service-001。所有层的数据都带上这个标识Agent查询的时候先拿到标识再去各层拉数据。注意统一标识看起来简单但实际落地时最容易出问题。我见过很多团队监控系统里叫payment日志系统里叫payment-serviceCMDB里叫支付服务Agent一查就懵了。建议在建工作空间之前先花一周时间把命名规范统一了磨刀不误砍柴工。2.2 Agent在工作空间里怎么“干活”工作空间建好了接下来要让Agent在里面干活。这里的关键是设计好Agent的“工具集”。Agent不是直接访问数据库的而是通过工具来操作。我一般给Agent配这几类工具查询类工具查指标、查日志、查依赖、查变更记录。这类工具是只读的Agent可以随便调不用担心搞出问题。分析类工具异常检测、趋势预测、相关性分析。这类工具封装了一些算法Agent不需要自己算直接调就行。操作类工具重启服务、扩容、回滚、修改配置。这类工具是写操作必须加审批或者二次确认。我的做法是初期全部禁用等Agent的准确率上来了再逐步开放。协作类工具创建工单、通知负责人、拉群。这类工具让Agent能和人协作而不是自己闷头干。工具集的设计原则是查询类要丰富分析类要精准操作类要克制。我见过有团队一上来就给Agent开放了重启权限结果Agent因为一个误判把生产环境的核心服务重启了虽然没造成大事故但把大家吓出一身冷汗。Agent调用工具的流程一般是这样的先理解用户的问题然后规划需要调哪些工具接着按顺序调用最后综合结果给出回答。这个过程和人在工作空间里排查问题是一模一样的。2.3 为什么不用“一个大Agent管所有系统”这是我在架构设计上纠结最久的一个问题。最初的方案是做一个“全能Agent”它能看到所有系统的工作空间用户问什么它查什么。听起来很美好但实际跑起来问题很多。第一个问题是上下文爆炸。四十多个系统的信息全塞给Agent光是系统列表就占了几千个token真正有用的信息反而被淹没了。Agent经常答非所问因为它被无关信息干扰了。第二个问题是权限混乱。不同系统有不同的负责人和权限要求一个大Agent很难做到精细化的权限控制。你不想让一个实习生通过Agent查到核心支付系统的敏感配置吧第三个问题是准确率下降。我做过对比测试同样的问题用“全能Agent”的准确率是62%用“每个系统一个专属Agent”的准确率是89%。差距非常明显。所以我的建议是每个系统建一个工作空间每个工作空间配一个专属Agent。用户提问时先路由到对应系统的Agent再由这个Agent在工作空间里干活。如果问题涉及多个系统就由多个Agent协作或者由一个“协调Agent”来调度。这个架构的好处是每个Agent的上下文是干净的权限是清晰的准确率也高。坏处是Agent数量多了之后管理成本上升但这个问题可以通过模板化来解决——大部分Agent的配置是相似的只有工具集和知识库不同。2.4 工作空间的“冷启动”怎么做新建一个工作空间最怕的是“空荡荡”。Agent进去一看什么信息都没有问它问题它也说不知道。所以工作空间的冷启动很重要。我的做法是分三步走第一步自动发现。写一个采集器从现有的监控系统、日志系统、CMDB、代码仓库里自动拉取信息填充工作空间的基础数据。这一步能解决80%的信息填充问题。第二步人工补全。自动发现拿不到的信息比如系统的业务含义、关键联系人、特殊注意事项需要人工补。我一般会做一个简单的表单让系统负责人花十分钟填一下。别小看这十分钟它能让Agent的回答质量提升一个档次。第三步历史沉淀。把过去半年的告警记录、工单记录、变更记录导入工作空间让Agent有“历史经验”可以参考。这一步是长期工程可以边用边补。冷启动做完之后工作空间就算“活”了。但要注意工作空间不是建完就不管了它需要持续更新。我的做法是每天自动同步一次基础数据每周人工review一次知识库每月做一次全面盘点。3. 从零搭建一个AI运维工作空间的完整实操3.1 环境准备与基础组件选型假设你现在要从零开始搭一套我把我用过的组件清单列一下都是经过生产验证的不是随便找的。组件类型推荐选型备选方案选择理由关系型数据库PostgreSQL 15MySQL 8JSON字段支持好适合存半结构化的资产数据时序数据库VictoriaMetricsPrometheus单机性能强运维简单兼容PromQL日志系统LokiElasticsearch资源占用低和Grafana集成好向量数据库QdrantMilvus部署简单API友好适合中小规模Agent框架LangChainLlamaIndex工具调用生态成熟社区活跃大模型本地部署开源模型商用API数据不出内网成本可控编排层自研轻量调度器Airflow运维场景不需要那么重的编排选型的原则是能用单机就不用集群能用开源就不用商业能本地部署就不上云。运维数据敏感而且量级通常没有互联网业务那么大单机方案足够撑住。环境准备的具体步骤# 以Ubuntu 22.04为例安装Docker和Docker Compose sudo apt update sudo apt install -y docker.io docker-compose-plugin # 创建数据目录 sudo mkdir -p /data/aiops/{postgres,victoria,loki,qdrant} sudo chown -R $USER:$USER /data/aiops # 启动基础组件docker-compose.yml片段version: 3.8 services: postgres: image: postgres:15 volumes: - /data/aiops/postgres:/var/lib/postgresql/data environment: POSTGRES_PASSWORD: your_password ports: - 5432:5432 victoria: image: victoriametrics/victoria-metrics:latest volumes: - /data/aiops/victoria:/victoria-metrics-data ports: - 8428:8428 qdrant: image: qdrant/qdrant:latest volumes: - /data/aiops/qdrant:/qdrant/storage ports: - 6333:6333这套环境在一台16核64G的机器上跑支撑五十个系统的工作空间没问题。如果系统数量更多可以把时序数据库和向量数据库拆出去单独部署。提示大模型的选择很关键。我试过用7B参数的模型做Agent工具调用的准确率只有70%左右经常调错工具或者参数传错。后来换成14B以上的模型准确率提升到90%以上。如果条件允许建议至少用14B的模型量化后的版本在24G显存的卡上能跑。3.2 工作空间元数据的建模与录入环境准备好之后开始建数据模型。我在PostgreSQL里建了这几张核心表-- 系统表 CREATE TABLE systems ( id SERIAL PRIMARY KEY, sys_key VARCHAR(128) UNIQUE NOT NULL, -- 统一标识如 prod-payment-service name VARCHAR(256) NOT NULL, env VARCHAR(32) NOT NULL, -- prod/staging/dev owner VARCHAR(128), description TEXT, created_at TIMESTAMP DEFAULT NOW() ); -- 依赖关系表 CREATE TABLE dependencies ( id SERIAL PRIMARY KEY, from_sys VARCHAR(128) NOT NULL, to_sys VARCHAR(128) NOT NULL, dep_type VARCHAR(64), -- rpc/db/cache/mq critical BOOLEAN DEFAULT FALSE, UNIQUE(from_sys, to_sys, dep_type) ); -- 资产表 CREATE TABLE assets ( id SERIAL PRIMARY KEY, sys_key VARCHAR(128) NOT NULL, asset_type VARCHAR(64), -- repo/image/config/dashboard asset_uri TEXT NOT NULL, extra JSONB, UNIQUE(sys_key, asset_type, asset_uri) ); -- 知识条目表 CREATE TABLE knowledge ( id SERIAL PRIMARY KEY, sys_key VARCHAR(128) NOT NULL, category VARCHAR(64), -- faq/runbook/incident title VARCHAR(512), content TEXT, embedding_id VARCHAR(128), -- 对应向量库里的ID created_at TIMESTAMP DEFAULT NOW() );建完表之后写一个采集脚本从现有系统里拉数据。我一般用Python写因为运维同学对Python最熟悉。import psycopg2 import requests def sync_systems_from_cmdb(): 从CMDB同步系统列表 resp requests.get(http://cmdb.internal/api/systems) systems resp.json() conn psycopg2.connect(dbnameaiops userpostgres passwordyour_password hostlocalhost) cur conn.cursor() for sys in systems: cur.execute( INSERT INTO systems (sys_key, name, env, owner, description) VALUES (%s, %s, %s, %s, %s) ON CONFLICT (sys_key) DO UPDATE SET name EXCLUDED.name, owner EXCLUDED.owner, description EXCLUDED.description , (sys[key], sys[name], sys[env], sys[owner], sys[desc])) conn.commit() cur.close() conn.close()这个脚本每天跑一次保证工作空间的元数据是最新的。依赖关系可以从服务网格或者调用链系统里拉资产信息可以从代码仓库和镜像仓库的API拉。录入的时候有个坑要注意不要一次性把所有系统都录进来。我建议先选三到五个核心系统做试点跑通了再逐步扩展。一次性全录进来数据质量问题会把你淹没而且Agent的表现不好你也找不到原因。3.3 Agent工具集的具体实现工具集是Agent和工作空间之间的桥梁。我用LangChain的Tool抽象来实现每个工具就是一个Python函数。from langchain.tools import tool import requests tool def query_metrics(sys_key: str, metric: str, duration: str 1h) - str: 查询指定系统的监控指标。 Args: sys_key: 系统标识如 prod-payment-service metric: 指标名称如 cpu_usage, qps, latency_p99 duration: 查询时间范围如 1h, 6h, 24h # 调用VictoriaMetrics的PromQL接口 query f{metric}{{sys{sys_key}}} resp requests.get( http://localhost:8428/api/v1/query_range, params{query: query, start: f-{duration}, step: 60s} ) data resp.json() # 简化返回只给Agent关键信息 values data[data][result][0][values] if data[data][result] else [] if not values: return f未查询到 {sys_key} 的 {metric} 指标数据 latest values[-1][1] max_val max(float(v[1]) for v in values) avg_val sum(float(v[1]) for v in values) / len(values) return f{sys_key} 的 {metric}当前值 {latest}最大值 {max_val:.2f}平均值 {avg_val:.2f} tool def query_logs(sys_key: str, keyword: str, duration: str 1h) - str: 查询指定系统的日志。 Args: sys_key: 系统标识 keyword: 搜索关键词如 error, timeout, exception duration: 查询时间范围 # 调用Loki的查询接口 end int(time.time() * 1e9) start end - parse_duration(duration) query f{{sys{sys_key}}} | {keyword} resp requests.get( http://localhost:3100/loki/api/v1/query_range, params{query: query, start: start, end: end, limit: 50} ) # 返回日志摘要 ... tool def query_dependencies(sys_key: str) - str: 查询指定系统的依赖关系。 conn psycopg2.connect(...) cur conn.cursor() cur.execute(SELECT to_sys, dep_type, critical FROM dependencies WHERE from_sys %s, (sys_key,)) deps cur.fetchall() cur.execute(SELECT from_sys, dep_type FROM dependencies WHERE to_sys %s, (sys_key,)) upstream cur.fetchall() ... return f下游依赖{deps}上游调用方{upstream} tool def query_changes(sys_key: str, duration: str 24h) - str: 查询指定系统最近的变更记录。 ...工具实现有几个要点第一返回值要精简。Agent的上下文窗口有限工具返回一大堆原始数据反而会干扰它。我一般只返回关键统计值和少量样本比如“最大值、平均值、当前值”和“最近三条错误日志”。第二参数要少而明确。工具的参数越多Agent调错的概率越大。我尽量把参数控制在三个以内而且参数名要直白比如sys_key、metric、duration。第三错误处理要友好。工具调用失败时不要抛异常而是返回一个描述性的错误信息让Agent知道发生了什么。比如“未查询到数据”比“KeyError”对Agent友好得多。第四工具描述要详细。LangChain的工具描述会作为prompt的一部分传给模型描述写得越清楚模型调用得越准确。我一般会在描述里写清楚参数的含义、格式、示例。3.4 把工作空间和Agent串起来工具写好了接下来要把它们和Agent串起来。我用的是LangChain的AgentExecutor配置如下from langchain.agents import AgentExecutor, create_openai_tools_agent from langchain.prompts import ChatPromptTemplate # 系统提示词这是Agent的“人设” SYSTEM_PROMPT 你是一个专业的运维助手负责帮助工程师排查 {sys_key} 系统的问题。 你可以使用以下工具来获取信息 - query_metrics: 查询监控指标 - query_logs: 查询日志 - query_dependencies: 查询依赖关系 - query_changes: 查询变更记录 工作原则 1. 先理解问题再规划需要查什么信息 2. 查询信息时优先查最近1小时的数据 3. 给出结论时必须基于查询到的实际数据不要臆测 4. 如果信息不足明确告诉用户还需要什么信息 5. 涉及操作类建议时必须提醒用户人工确认 当前系统{sys_key} 系统描述{sys_desc} prompt ChatPromptTemplate.from_messages([ (system, SYSTEM_PROMPT), (human, {input}), (placeholder, {agent_scratchpad}), ]) # 为每个系统创建一个Agent实例 def create_system_agent(sys_key, sys_desc, tools): agent create_openai_tools_agent(llm, tools, prompt) return AgentExecutor( agentagent, toolstools, verboseTrue, max_iterations10, # 防止Agent陷入死循环 handle_parsing_errorsTrue, ) # 路由层根据用户问题找到对应的系统 def route_question(question): # 简单实现用关键词匹配 for sys_key in all_systems: if sys_key in question or all_systems[sys_key][name] in question: return sys_key # 复杂实现用一个小模型做意图分类 return classify_intent(question)这里有几个实操心得max_iterations一定要设。我试过不设限制Agent有时候会陷入“查了指标觉得不够又去查日志查完日志觉得不够又去查指标”的死循环烧了一堆token还没给出答案。设成10次一般够用。verbose模式在调试时开生产时关。verbose会把Agent的每一步思考都打出来调试的时候很有用但生产环境日志量太大。路由层是必须的。不要让用户手动指定系统那样体验太差。用关键词匹配做第一版就行准确率不够再上模型分类。每个系统的Agent要独立配置。不同系统的工具集可能不一样比如有的系统没有配置中心那就不需要查配置的工具。独立配置能让Agent更专注。3.5 一个完整的排查案例演示说了这么多理论来看一个实际案例。用户问“支付服务今天下午开始变慢了帮我看看什么原因。”路由层识别出sys_key prod-payment-service把问题转给支付服务的Agent。Agent的思考过程简化版第一步调用query_metrics查延迟指标query_metrics(sys_keyprod-payment-service, metriclatency_p99, duration6h)返回当前值 1250ms最大值 1800ms平均值 320ms。说明下午确实有延迟飙升。第二步调用query_metrics查QPSquery_metrics(sys_keyprod-payment-service, metricqps, duration6h)返回当前值 1200最大值 1250平均值 1180。QPS没有明显变化排除流量突增。第三步调用query_dependencies查依赖query_dependencies(sys_keyprod-payment-service)返回下游依赖 config-center配置中心、mysql-main、redis-cache。第四步调用query_metrics查下游依赖的延迟query_metrics(sys_keyconfig-center, metriclatency_p99, duration6h)返回config-center 的延迟从下午2点开始从 5ms 飙升到 800ms。第五步调用query_changes查配置中心的变更query_changes(sys_keyconfig-center, duration24h)返回下午1点50分有人修改了配置中心的连接池大小从 200 改成了 20。Agent综合以上信息给出结论“支付服务变慢的根因是配置中心在下午1点50分进行了变更连接池从200缩小到20导致配置读取延迟飙升进而拖慢了支付服务。建议回滚该变更或调大连接池。”整个过程Agent调用了五次工具耗时约15秒。如果人工排查至少需要20分钟。这就是工作空间Agent的价值。注意这个案例里Agent能定位到根因关键在于工作空间里有完整的依赖关系和变更记录。如果只接了监控指标Agent最多只能告诉你“支付服务变慢了配置中心也变慢了”但没法建立因果关系。所以再强调一遍五件套要完整。4. 落地过程中最容易踩的坑与排查手册4.1 Agent答非所问的五个常见原因这是最常见的问题。你问AAgent答B或者答得云里雾里。我总结了五个原因和对应的解法现象可能原因排查方法解决方案Agent调用工具时参数传错工具描述不清晰看verbose日志里Agent传的参数完善工具描述加参数示例Agent查了无关的系统路由层匹配错误检查路由层的匹配逻辑改用模型做意图分类Agent给出臆测的结论系统提示词约束不够看Agent是否基于实际数据回答在提示词里强调“必须基于数据”Agent反复查同一个工具max_iterations没设或太大看日志里工具调用次数设max_iterations10加去重逻辑Agent回答太啰嗦提示词没有输出格式要求看回答长度在提示词里规定输出格式和字数我重点说一下“Agent给出臆测结论”这个问题。大模型有个毛病就是它倾向于给出一个“看起来合理”的答案哪怕它没有足够的信息。在运维场景里这很危险因为一个错误的结论可能导致错误的操作。我的解法是在系统提示词里加一条硬约束“如果你没有查询到相关数据必须明确说‘未查询到数据无法判断’禁止基于常识或经验给出推测性结论。”这条约束加上之后Agent的“幻觉率”明显下降。另外我还会在Agent给出结论后做一个“事实校验”把Agent的结论和它查询到的数据做比对如果结论里提到的数字在查询结果里找不到就标记为可疑。这个校验可以用简单的字符串匹配实现不需要模型。4.2 工作空间数据不同步的排查思路工作空间的数据来自多个系统不同步是常态。我遇到过这几种情况监控指标延迟。Prometheus默认15秒抓一次VictoriaMetrics可能有额外的写入延迟。如果Agent查的是最近1分钟的数据可能查不到。解法是在工具里把查询时间范围往前推5分钟或者明确告诉Agent“最近5分钟的数据可能不完整”。日志采集延迟。Loki的采集链路是Promtail - Loki中间可能有几十秒的延迟。如果Agent查“刚刚发生的错误”可能查不到。解法是让Agent查“最近5分钟”而不是“最近1分钟”。CMDB更新延迟。CMDB的数据往往是人工维护的更新不及时。如果新上线的服务没录入CMDBAgent就查不到。解法是做一个自动发现机制从Kubernetes的API里自动同步服务列表和CMDB做比对发现差异就告警。依赖关系过期。服务之间的依赖关系是动态变化的今天A依赖B明天可能就不依赖了。如果依赖关系没更新Agent的分析就会出错。解法是定期从服务网格或者调用链系统里重新拉取依赖关系每周更新一次。排查数据不同步的问题我的经验是先看数据源再看采集链路最后看工作空间。大部分问题出在数据源本身而不是工作空间。4.3 权限与安全的红线怎么划AI运维涉及生产系统权限和安全是红线。我的做法是“三层隔离”第一层网络隔离。工作空间的各个组件部署在内网不暴露公网。Agent访问工具走内网API不走公网。第二层数据隔离。不同系统的工作空间数据在逻辑上隔离Agent只能访问自己系统的数据。敏感数据如数据库密码、密钥不进入工作空间Agent查询时返回脱敏后的结果。第三层操作隔离。查询类工具直接开放分析类工具记录审计日志操作类工具必须人工审批。我一般会做一个审批流Agent提出操作建议推送给系统负责人负责人确认后才执行。提示不要给Agent开放“删除”类操作哪怕是测试环境。我见过一个案例Agent在测试环境误删了一个数据库虽然可以恢复但浪费了半天时间。删除操作永远应该由人来做。另外Agent的对话记录要保存至少保存半年。这不仅是审计要求也是改进Agent的依据。我每周会抽看一些对话记录看看Agent哪些问题答得好哪些答得不好然后针对性地优化提示词和工具。4.4 成本控制的实操经验大模型调用是有成本的尤其是用商用API的时候。我算过一笔账一个中等规模的集群每天大概有200次Agent调用每次调用平均消耗3000个token包括系统提示词、工具调用、工具返回、最终回答一天就是60万token。如果用商用API一天的成本大概在几十到几百元不等。控制成本有几个办法第一缓存常用查询。有些查询是重复的比如“支付服务的QPS是多少”可能一天被问十几次。我加了一层缓存同样的查询5分钟内直接返回缓存结果不调模型。第二精简系统提示词。系统提示词每次调用都要传如果写得太长成本会很高。我一般控制在500字以内只保留最关键的约束。第三工具返回精简。前面说过工具返回的数据要精简这不仅是为了Agent的准确率也是为了省token。返回一堆原始数据token消耗会翻好几倍。第四用本地模型做初筛。简单的查询比如“查一下CPU使用率”用本地的小模型处理复杂的分析才用大模型。这样能省不少钱。第五设置每日限额。给每个系统设一个每日token限额超了就停止服务第二天恢复。这能防止异常调用把预算烧光。我实测下来用本地部署的14B模型一台24G显存的机器每天处理500次调用没问题成本就是电费。如果预算有限建议优先考虑本地部署。4.5 常见问题速查表最后整理一份速查表都是我实际遇到过的问题问题排查步骤解决方案Agent不调用工具直接回答检查工具是否注册成功确认tools列表非空检查工具描述Agent调用工具报错看verbose日志里的错误信息检查工具函数的参数类型和返回值Agent回答超时看max_iterations和工具耗时减少max_iterations优化工具查询性能工作空间查不到数据检查数据源和采集链路确认数据已写入检查查询语句Agent回答不准确检查工作空间数据完整性补全五件套完善系统提示词模型响应慢检查模型部署的硬件资源升级GPU或换用更小的量化模型多个系统问题混淆检查路由层匹配逻辑改用模型做意图分类加系统隔离这份表我贴在工位上遇到问题先查表能解决80%的常见问题。剩下的20%需要具体分析但有了这份表至少不会像无头苍蝇一样乱撞。5. 工作空间的扩展方向与长期演进5.1 从单系统到多系统协作单个系统的工作空间跑通之后下一步自然是多系统协作。比如用户问“支付服务变慢是不是因为订单服务的问题”这就需要两个系统的Agent协作。我的做法是引入一个“协调Agent”它不直接查数据而是负责调度。协调Agent收到问题后先拆解成子问题分发给对应的系统Agent收集结果后再综合。协调Agent的实现比系统Agent简单它不需要工具集只需要一个“分发”工具和一个“汇总”工具。但难点在于子问题的拆解和结果的融合这需要比较强的推理能力建议用大一点的模型。多系统协作的典型场景包括跨系统的故障排查、容量规划、变更影响分析。这些场景单系统Agent搞不定必须多Agent协作。5.2 从被动问答到主动巡检现在的工作空间是“被动”的用户问什么它答什么。下一步是让它“主动”起来定期巡检发现问题主动告警。主动巡检的实现方式是给每个系统的工作空间配一个定时任务每隔一段时间比如5分钟自动跑一遍检查项包括核心指标是否异常、是否有新的错误日志、是否有未预期的变更。发现异常就推送给负责人。主动巡检的关键是“降噪”。如果巡检太频繁告警太多大家就会麻木。我的做法是只对“确认异常”的情况告警疑似异常先记录不告警。确认异常的判断可以用规则模型结合的方式规则做初筛模型做确认。5.3 从运维场景到研发场景的延伸工作空间的思路不仅适用于运维也适用于研发。比如给每个代码仓库建一个工作空间把代码、CI/CD流水线、测试报告、代码评审记录都放进去配一个Agent帮开发者查问题。我试过在代码评审场景用这个思路Agent自动检查代码变更是否影响了依赖的系统是否有对应的测试覆盖是否有性能风险。效果不错能帮评审人省不少时间。研发场景的工作空间和运维场景的工作空间底层架构是一样的只是数据源和工具集不同。所以前期投入建工作空间的成本可以在多个场景复用这是很划算的。5.4 我个人的一些体会做AI原生运维这一年多我最大的体会是技术不是瓶颈数据才是。大模型的能力已经足够强了Agent框架也很成熟真正难的是把数据整理好、把工作空间建好。我见过太多团队模型选型纠结了两个月工作空间的数据却乱七八糟最后做出来的东西没法用。另一个体会是不要追求全自动。AI运维的目标不是取代人而是帮人省时间。Agent能帮你把排查时间从20分钟缩短到2分钟这就很好了。剩下的2分钟让人来做决策这样既高效又安全。最后一个体会是从小处着手。不要一上来就搞大平台先选一个系统建一个工作空间配一个Agent跑通一个场景。跑通之后再复制到其他系统。我见过太多“大平台”项目做了一年还在开发而小步快跑的项目已经上线半年了。这个方向后续还可以扩展很多比如把工作空间和混沌工程结合让Agent在故障演练中学习比如把工作空间和容量管理结合让Agent做资源预测。但这些都是后话先把基础的工作空间建好把五件套填满把Agent调准比什么都重要。