企业官网建设流程全解析

最近圈子里聊得最多的一个词，已经从“大模型”换成了“主动型AI”，英文叫 proactive AI，也有人叫 agentic AI。硅谷几个头部AI团队几乎同时把产品定位从 chatbot 改成了“AI员工”、“AI同事”，这绝不是文案上的赶时髦，而是产品逻辑一次非常本质的转向：从“你说一句，我回一句”变成“我根据你的目标和环境，自己判断下一步该干什么，然后直接把它办了”。

聊天机器人解决的是信息获取和简单问答的问题，主动型AI要解决的是任务闭环的问题。举个很直接的例子，你让AI“帮忙盯一下线上服务的健康状态，发现流量突增就自动排查并告警，顺便把结论发到工作群”，这在纯聊天机器人时代是无法想象的，因为它没有目标、没有工具、没有主动触发机制。而主动型AI可以把这件事完整接下：它有自己的任务清单，会主动调用监控接口，会在授权范围内执行操作，最后给你一份带结论的汇报。

这篇文章适合三类人看：正在做大模型应用开发、已经厌烦“套壳聊天”的工程师；在评估AI产品方向、想搞懂“主动型AI到底和Agent有什么区别”的产品经理；以及企业内部负责AI落地、想算清楚投入产出比的技术负责人。我会从趋势、架构、代码、坑点四个角度展开，尽量说人话，把我在实际项目中遇到的问题和取舍都写出来。

1. 别把主动型AI理解成“会自己说话的聊天机器人”

这一轮转变被讨论得最多，也误解得最多。很多人觉得主动型AI就是聊天机器人加了一个定时器，到点自动说两句话。如果真这么简单，就不会有那么多团队重写整套架构了。

1.1 聊天机器人到底“过时”在哪

聊天机器人的核心交互范式是“请求-响应”：用户发起提问，机器人返回答案。这个模式在FAQ、知识问答、内容生成场景里很好用，但有几个致命短板一直解决不了。

第一，它对“用户没说的变化”毫无感知。线上服务半夜挂了，聊天机器人不会知道，也不会有任何动作，它只能等第二天有人来问“昨晚怎么回事”。第二，它无法持续推进长周期任务。你让它“帮我整理季度经营分析”，它只能给你生成一份大纲，后面的数据拉取、图表制作、格式调整，每一步都需要你重新发指令。第三，用户使用成本高。所有事情都必须人来发起，AI只是被动的“应答器”。

所以“过时”不是否定聊天交互的价值，而是说在任务执行这个层面，纯问答形态撑不起真正的效率提升。我在和一些做企业服务的同行交流时，大家的反馈很一致：客户已经不怎么为“能聊”买单了，他们问得最多的是“这个AI能不能自己把报表跑了、把工单处理了、把告警查了”。

1.2 主动型AI的核心特征：从回答问题到替你办事

我给主动型AI下过一个比较朴素的定义：一个能自主感知环境、制定计划、调用工具、验证结果并持续改进的智能体系统。它和聊天机器人最大的区别有四点。

• 目标导向：用户给的是一件事，而不是一句话。比如“每天上午10点检查服务器磁盘空间，不足20%就清理临时文件并汇报”。
• 自主规划：AI会自己拆解步骤，先查什么、再看什么、最后做什么，步骤是可解释、可监控的。
• 工具调用：它能实际操作真实系统，不是只输出文字，而是真的去调接口、查日志、发消息。
• 闭环反馈：执行完不是终点，还要验证结果有没有达到预期，失败了要重试或者求助人工。

用生活类比来说，聊天机器人像商场里的客服专员，你问什么它答什么，问完就结束；主动型AI更像一个贴身助理，他会提前帮你做好行程规划，航班延误了主动改签，甚至在你还没意识到问题的时候就把隐患处理掉了。客户要的不是一个“知道答案的人”，而是一个“能把事办完的人”。

2. 为什么偏偏是现在才开始“卷”主动型AI

主动型AI的概念其实不是新东西，学术界十多年前就有规划和智能体的研究。但过去一直无法产品化，因为底层能力不够。这两年情况变了。

2.1 三个底层能力叠加到位

第一个关键变化是模型的工具调用能力稳定了。现在主流大模型在函数调用场景下，已经能比较可靠地输出结构化参数，不再只是生成一段带格式的文本。这意味着AI可以真正驱动外部工具，而不是“假装调用”然后自己编一个结果。

第二个变化是上下文窗口和推理能力的提升。主动型AI在执行复杂任务时，需要在内部系统提示词、任务计划、工具执行历史、结果摘要之间反复切换。过去窗口太小，轮数一多就丢信息，现在大窗口加上自适应压缩技术，让多步骤执行变得可行。

第三个变化是生态层的标准化。各类工具和数据的接入方式正在收敛，模型连接外部系统不再需要为每个API写一套私有协议。这种标准化的价值很像USB接口统一了外设连接，它最大程度降低了主动型AI接入企业系统的边际成本。

2.2 商业模式和市场需求的助推

这波风潮背后有很现实的资本逻辑。前两年市场对AI的期待是“能聊天、能写文案、能画画”，但创业公司迟早要回答一个问题：你的产品到底帮客户省了多少钱？纯聊天产品的付费意愿很容易见顶，而“AI员工”这类叙事直接挂钩降本增效，投资人听得懂，企业客户也更容易签单。

我观察到硅谷几个明星创业公司的融资故事，已经全部从“我们的AI多聪明”换成了“我们的AI能替企业完成哪些具体岗位的工作”。产品形态也从聊天窗口变成了工作台、仪表盘、自动化流程。需求端同样在变，企业客户不再满足于让AI当百科全书，而是希望它直接走进业务流程，把原来需要专人盯守的重复工作接走。

所以“卷主动型AI”不是技术圈自嗨，是模型能力、基础设施、商业模式三条曲线正好走到同一个交叉点。对从业者来说，这意味着主动型AI从研究课题变成了工程赛道，也正是入局的好时机。

3. 主动型AI的架构拆解：五个必须想清楚的模块

热情归热情，落地又是另一回事。我在做主动型AI项目时，发现它和做聊天机器人完全是不同的架构难度。下面五个模块，基本决定了一个主动型AI系统能不能在真实场景里活下来。

3.1 意图识别与触发策略：什么情况下AI该主动出手

主动型AI和聊天机器人最大的区别在于“谁先说话”。这带来一个很实际的问题：让AI自主决定何时行动，它凭什么触发？我的经验是把触发方式分成四类，按确定性从高到低排序。

• 定时触发：用cron表达式控制，比如每天早上9点执行巡检任务。
• 事件触发：接收外部系统的webhook，比如收到新工单或部署完成事件时启动任务。
• 异常值触发：监控指标超过阈值时触发，比如CPU使用率超过80%自动进入排查流程。
• 用户指令触发：用户给一个模糊目标，比如“帮我整理上周的用户反馈”，AI自己规划并执行。

实际项目中不需要四种全上，核心是把“触发策略”做成一个可配置的规则引擎。前期尽量用高确定性的定时和事件触发，等模型对业务理解足够稳定后，再逐步放开异常值触发和开放指令触发。不然一上来就让AI自己判断何时动手，很容易频繁误触发，把用户吓到。

3.2 任务规划与执行：把大目标拆成可执行子任务

触发只是开始，真正复杂的是规划。同样是一个目标，AI可以选择先查资料、再定方案、然后执行，也可以选择直接给出结论。不同路线消耗的时间和成本差别很大。

我在落地时推荐“Plan-and-Execute”模式，不是让模型一步步自由发挥，而是先让模型输出一个完整计划，比如：

1. 检查数据库连接池状态
2. 拉取最近1小时错误日志
3. 分析慢查询Top 10
4. 生成处理建议并发送给值班群

这个计划会落到一个结构化存储里，然后由执行引擎按步骤调度。这样做的优势很明显：每一步都是可回滚的，用户随时能看到进度，执行到某一步失败时也能清晰定位。切忌让模型在完整计划未确定时就开始调用工具，那样不仅成本高，而且AI很容易钻到细节里出不来。

计划阶段还要定义“终止条件”。比如“磁盘空间不足20%时需要清理”是一个明确目标，但如果清理完仍不足20%，AI必须停下来求助人工，而不是无限扩大清理范围。没有明确终止条件的任务，很容易变成失控的自动程序。

3.3 工具调用与权限边界：能做什么和不能做什么

主动型AI的能力上限由工具决定，风险上限也由工具决定。我见过不少团队把模型接到一堆内部API上，然后让模型“自由调用”，结果模型在某个测试环境里把配置改了，吓得大家连夜加鉴权。

我的建议是建立一个工具注册表，每个工具都要声明三样东西：参数schema、调用权限、操作级别。操作级别至少分三级：

• 只读：查询类操作，比如读日志、查指标，可以自动执行。
• 可写：修改类操作，比如发消息、提交工单，需要留痕并允许撤销。
• 高危：影响面较大的操作，比如重启服务、删除数据、发布变更，强制要求人工确认。

工具调用路径一定要收口，不能允许模型直接拼一个URL去访问内网API。所有工具走统一网关，模型只输出“要调哪个工具、传什么参数”，网关负责鉴权、限流、审计。这就好比给AI配了一把带权限列表的钥匙，而不是把整个机房的钥匙串都交给它。

3.4 记忆与上下文管理：跨会话保持一致性

聊天机器人的记忆只需要一个会话窗口，主动型AI则需要多层次的记忆结构。我把它分成三层：

• 短期记忆：当前任务的状态、已执行的步骤、中间结果，存在Redis里方便快速读写。
• 长期记忆：用户偏好、历史任务结论、常见问题的处理方式，存入向量数据库。
• 业务上下文：系统提示词、任务计划、工具执行结果摘要，拼装后发给模型。

这里有个常见误区，就是在上下文管理上直接沿用聊天机器人的思路，把所有历史一股脑塞给模型。主动型AI跑几轮工具调用之后，上下文会迅速膨胀，token成本飙升，模型也容易被噪声干扰。更好的做法是每步只保留必要信息，工具结果做摘要裁剪，历史结论存进长期记忆里，下次任务直接读取摘要，而不是重新翻旧账。

3.5 反馈闭环与自我修正：错了要能收住

主动性不等于无人值守。一个成熟的主动型AI系统，一定要有反馈闭环和人工兜底机制。

每执行完一步，都要比对“预期结果”和“实际结果”是否一致。如果模型打算调用某个工具，但工具返回报错，它应该能理解错误信息，修正参数后重试，或者换一个方案。如果重试多次无果，系统要自动降级，比如把任务状态标记为“需人工介入”，并给负责人发一条包含上下文摘要的通知。

反馈闭环还意味着每一次主动行为的最终结果要回写记忆库。这个月处理过的故障、使用过的排查思路，下次遇到类似问题时可以直接复用，越用越顺手。主动型AI的价值曲线是随着使用时间上升的，关键就在于这个反馈闭环有没有真正落地，而不是每次从零开始。

4. 手把手搭一个主动型AI：以“自动巡检机器人”为例

前面讲了一堆原则，下面用一个具体的例子把方案落地。我挑的场景非常有代表性：一个小型技术团队，核心服务频繁出现偶发问题，希望AI每小时自动检查服务健康状态、登录日志和依赖接口延迟，发现问题自动排查并推送摘要到工作群。高危操作如重启服务，需要经过负责人确认才能执行。

4.1 场景定义与系统架构

这个场景在聊天机器人时代几乎没法做，因为它的核心需求不是“回答用户问题”，而是“主动盯守并处理”。系统模块大致分成五块：

• 触发层：定时任务调度器，每小时触发一次巡检计划。
• 规划层：大模型根据巡检目标生成具体的排查步骤，并把计划存入任务状态表。
• 执行层：工具路由器接收模型输出的工具调用指令，做鉴权后转发给对应工具。
• 工具层：核心包括健康检查接口、日志查询接口、消息推送接口、服务重启接口。
• 反馈层：每步执行结果回传模型，最终结论写入长期记忆，异常事件触发人工通知。

模块之间用异步消息解耦，触发层不关心执行层怎么处理，执行层不关心消息最终发到哪个渠道。这样后续替换模型或新增工具时，不需要大改系统。

4.2 核心代码实现

我写一个简化版的核心逻辑，用Python风格实现，重点展示“计划-执行-反馈”的主循环。生产环境需要补充异常处理、鉴权、状态恢复等细节，但骨架是完整的。

# 简化版主动型巡检Agent import requests from datetime import datetime from typing import Dict, List # 1. 工具注册表：每个工具声明参数和操作级别 TOOLS = { "check_service_health": { "params": ["service_name"], "level": "read", # 只读 }, "query_recent_logs": { "params": ["service_name", "minutes"], "level": "read", }, "send_group_message": { "params": ["channel", "content"], "level": "write", # 可写，需要留痕 }, "restart_service": { "params": ["service_name"], "level": "danger", # 高危，必须人工确认 }, } # 2. 调用LLM，让它根据观测结果决定下一步动作 def llm_decide(system_prompt: str, context: str) -> Dict: payload = { "model": "your-llm-model", "messages": [ {"role": "system", "content": system_prompt}, {"role": "user", "content": context}, ], "tools": [ {"type": "function", "function": {"name": name, "parameters": schema}} for name, schema in TOOLS.items() ], "tool_choice": "auto", } # 实际项目中走统一的模型网关，这里省略鉴权和熔断逻辑 resp = requests.post("http://localhost:8000/v1/chat/completions", json=payload) resp.raise_for_status() data = resp.json() return data["choices"][0]["message"] # 3. 模拟工具实现 def call_tool(name: str, args: Dict) -> Dict: if name == "check_service_health": return {"service": args["service_name"], "status": "ok", "latency_ms": 120} elif name == "query_recent_logs": return {"logs": ["connection_pool_warning", "slow_query_detected"]} elif name == "send_group_message": print(f"[消息已发送] {args['channel']}: {args['content']}") return {"status": "sent"} elif name == "restart_service": # 高危操作不直接执行，这里只返回待确认 print(f"[高危操作需确认] 重启服务: {args['service_name']}") return {"status": "pending_confirmation"} return {"status": "unknown_tool"} # 4. 主循环：每小时触发一次 def run_inspection_round(): services = ["order-service", "user-service", "pay-service"] system_prompt = ( "你是团队巡检助手。根据观测数据判断系统风险，可以调用工具。" "只允许调用已登记的工具，操作级别为danger的动作必须等待人工确认。" "若发现异常，把结论和下一步建议整理后发送到值班群。" ) for svc in services: context = f"服务名称: {svc}\n巡检时间: {datetime.now()}\n" # 第一步：检查健康状态 health = call_tool("check_service_health", {"service_name": svc}) context += f"健康状态: {health}\n" # 第二步：拉取最近的日志 logs = call_tool("query_recent_logs", {"service_name": svc, "minutes": 30}) context += f"最近日志摘要: {logs}\n" # 第三步：让LLM基于观测结果做决策 decision = llm_decide(system_prompt, context) if "tool_calls" in decision: for call in decision["tool_calls"]: fn = call["function"] result = call_tool(fn["name"], json.loads(fn["arguments"])) if fn["name"] == "restart_service": # 这里应该发送一条许可请求，等负责人回复后执行 print(f"已请求{svc}重启确认，等待人工批准") else: print(f"工具执行结果: {fn['name']} -> {result}") else: # LLM认为无需工具调用，直接输出结论 print(f"巡检结论: {decision.get('content', '无异常')}") # 生产环境用APScheduler或Celery Beat替代这个简单循环 if __name__ == "__main__": run_inspection_round()

这段代码的核心思想是“把模型当成决策器，把工具真正当成执行器”。模型输出的是“要不要调工具、调哪个、传什么参数”，真正的动作由本地工具函数完成，结果再回传。这样可以做到所有操作留痕，也能在这层做权限控制。简单说就是模型可以提方案，但执行权始终掌握在可控的代码手里。

实际项目中，还要把这个主循环升级成带状态机制的任务系统。比如把任务计划、执行进度存到数据库里，服务重启后可以从中断的地方继续跑；每个动作都生成一个trace_id，方便后续审计；发送消息时把多条结果合并成一条摘要，避免频繁刷屏。

4.3 部署与运营配置要点

代码写完后，真正花时间的反而是部署和运营配置。我根据经验列几个关键点。

调度器单独跑一个进程，不要和业务服务混在同一个进程里，否则AI任务一重CPU就飙到100%，影响线上业务。定时器建议用APScheduler这类成熟库，支持动态添加任务、失败重试。

工具调用网关要设超时和重试策略。一般外部接口的响应时间方差很大，如果不设置超时，一个卡住的工具会把整个任务卡死。我习惯把工具超时设为5秒，重试两次，仍失败则跳过该工具并记录告警。

模型输出的工具参数一定要做schema校验。模型偶尔会生成缺失参数或非法枚举值，不能直接透传给内部系统。用JSON Schema做一层校验，不合法的直接拒绝并让模型修正。

消息推送要做频控。主动型AI很容易变成话痨，每小时发几十条告警，最后大家都屏蔽了群消息。更好的做法是优先级分档，严重问题立即推送，一般提示聚合到日报里。

5. 主动型AI的应用场景和落地优先级

技术架构说完了，聊聊大家更关心的：这玩意到底能用在哪儿，哪些场景值得先做。

5.1 高价值场景：客服、运维、助理、营销

第一个场景是智能客服工单处理。传统客服机器人只能回答问题，主动型AI可以做到从工单创建、相似历史工单匹配、自动回复到超时预警的全流程处理。AI先自己尝试解决，解决不了再转人工，转人工时带着完整上下文，客服不需要让用户重新描述一遍问题。

第二个场景是运维告警与故障排查。这是我落地最多的场景，也就是上面demo做的事。AI从监控系统的被动接收者变成主动巡检者，能够在用户感知到问题之前就发现隐患，并给出排查结论和处置建议。对运维团队来说，省下的是每天盯监控、翻日志的大量重复工时。

第三个场景是个人和工作助理。比如自动整理邮件、根据日历冲突主动协调会议时间、出差前自动预订行程并生成行程单。这个方向最大的挑战是权限，毕竟个人邮箱、日历、支付信息都敏感，所以产品形态往往先从“建议+一键执行”做起。

第四个场景是数据运营。AI每天定时抽取数据，做异常检测和归因分析，发现指标波动后主动生成分析报告推送给业务负责人。传统BI工具是“人找数据”，主动型AI是“数据找人”，这个体验差异对决策者来说是很直观的。

5.2 低风险、好落地的切入口

如果团队是第一次做主动型AI，我的建议是别一上来就碰高风险场景。先避开三种场景：直接涉及资金交易的、自动对外发布内容的、需要访问核心用户隐私数据的。

更稳妥的切入路径是“只读+建议”模式。AI先做信息采集和分析，生成一份待办建议，用户点一下“执行”按钮后才真正操作。比如AI分析完日志后说“发现连接池耗尽风险，建议重启服务”，但重启动作必须由用户在页面上确认。这种模式既保留了主动性，又给了用户掌控感，特别适合初期积累信任。

等AI在“建议模式”下运行一段时间，积累了足够的历史执行记录和人工反馈之后，再逐步开放“自动执行”权限，而且最好先从影响范围小、可以回滚的操作开始。信任不是拍脑袋给的，是用一条条可审计的执行记录换来的。

5.3 商业化评估：主动型AI的价值怎么算

判断一个主动型AI项目值不值得投，我一般用“节省工时+减少损失”双重算法。

节省工时比较好算。比如一个5人运维团队，每天约花3小时盯监控和处理告警。AI接管后每人每天省下2小时，团队整体就是10小时/天，按一个月22个工作日计算，就是220小时的人力释放。这笔账很快就能算清楚。

减少损失是更大的价值，只是不太好量化。比如AI提前30分钟发现线上故障，避免了影响核心交易，这个损失金额可能远超人力成本。实际汇报时，我会用“避免损失场景”作为加分项，但做预算时还是按节省工时来算，这样更扎实，不容易被挑战。

还有容易被忽略的一点是隐藏成本：模型API调用费、工具网关的维护成本、人工处理AI误报的时间成本。这些都要计入ROI，否则上线后会发现自己做了个“越自动化越亏钱”的系统。

6. 避坑指南：主动型AI的七个常见问题与排查思路

这部分是干货中的干货。主动型AI踩坑的地方和传统应用完全不同，我把实际遇到的问题整理成了一张速查表，再逐个展开讲。

6.1 无限循环：AI反复执行同一个动作

现象：AI在同一个工具上反复调用，参数只差一点点，结果永远不对，但模型还在不停重试。

原因主要是没有设置步骤上限，以及工具结果没有真正回传上下文。模型可能认为自己第一次调用“没成功”，于是重新生成几乎相同的参数再试一次。

解法：全局步骤数硬上限，比如单任务最多执行15步，超过就强制终止；增加“重复状态检测”，当相邻3次工具调用的参数和返回结果基本一致时，判定为死循环并停止；同时把工具返回的真实状态码和错误信息完整回填给模型，让它有足够信息做不同决策。

6.2 权限越界：AI访问了不该访问的东西

现象：模型自主调用了一个未授权的高权限接口，虽然没有造成事故，但审计日志中出现了越权记录。

原因多半是工具网关没有做统一鉴权，模型甚至能直接通过构造URL访问内部系统。你以为只暴露了三个工具，实际模型从文档或上下文里“学会”了更多接口。

解法：所有工具必须走统一网关，模型只能调用注册表中的工具名；网关层做用户、角色、操作级别三重校验；高危接口默认不注册给模型，如果确实需要，要通过白名单单独开权限。原则是“默认拒绝，按需开放”。

6.3 上下文爆炸：token成本快速失控

现象：单次主动任务消耗几十万token，账单一个月暴涨，而且模型响应速度越来越慢。

原因在于把工具执行的完整返回结果全部塞回上下文，几轮循环下来，历史数据占据了绝大部分窗口。

解法：工具结果裁剪，只保留关键字段，比如日志查询只保留错误级别和错误数量，而不是全部日志原文；历史对话做滑动窗口，只保留最近N轮和当前目标的摘要；长期记忆定期压缩，把已经完成的任务细节聚合删掉，只留结论。这些手段加在一起，通常能把token消耗降到原来的1/5以下。

6.4 用户被打扰：AI变成了“话痨”

现象：AI每小时推送好几条消息，用户开始不看、屏蔽，甚至直接卸载。

原因不是AI不聪明，而是主动性没有和用户注意力管理结合起来。每一条消息都消耗用户的注意力资源，频繁打扰会让“主动”变成“骚扰”。

解法：建立消息分级制度，严重告警立即推送，一般提示进日报；多条结果合并发送，比如“今天解决了3个问题”而不是分3条发；设置免打扰时段，非紧急消息可以延迟到用户设定的可接收时间段。判断一条消息要不要立刻发，标准只有一个：用户不看它会不会出事。

6.5 评测困难：没法用单一指标衡量好坏

现象：主动型AI没有标准benchmark，同一个系统在不同测试数据下结论差异很大，团队不知道版本迭代后到底是变好了还是变差了。

解法是搭一套组合评测体系，至少看三个指标：任务成功率，即最终目标达成的比例；资源消耗，即平均每任务的token数和步骤数；人工干预率，即用户或管理员介入的次数。这三个指标要放在一起看，比如人工干预率低不一定是好事，可能是AI在回避复杂任务、专挑简单的执行。更细的做法是按场景拆分数，把“自动处理成功”和“错误中断”严格分开记录。

6.6 可解释性与审计：AI动了手，责任怎么划

现象：系统自动执行了一个操作，事后发现有问题，但没人能说清楚当时AI为什么这么决策。

原因是没有完整的执行链路记录。只知道AI做了什么，不知道它基于什么信息、为什么这么决策、是谁授权的。

解法：为每个任务维护一条完整的trace，包含触发条件、规划步骤、模型决策原始输出、工具参数、执行时间、执行人（如果是人工确认）等信息。哪怕最终没有出错，这些记录也应该保留，因为它是以后排查问题、优化提示词、定责任边界的基础。没有审计日志的主动型AI，上线了也是悬在头上的风险。

6.7 模型幻觉导致错误行动

现象：工具调用明明失败了，模型却根据“猜测”生成了一段成功的结果，后续步骤全部基于这个假结果展开，最终结论完全失真。

原因是大模型倾向于生成流畅连贯的内容，当工具返回信息缺失或报错时，模型可能会“脑补”一个合理的结果，而不是诚实地说“我不知道”。

解法：工具调用后强制校验返回状态，只允许真实结果写入上下文，状态异常时优先提示错误而不是让模型补全；关键动作加外部校验，比如AI说“已发送通知”，那就去消息平台确认发送记录；系统提示词里明确强调“工具返回失败时必须如实报告，不得猜测结果”。这一步做好了，能减少大部分看似诡异、实则全是幻觉的执行错误。

7. 写在最后：给入局者的一句实在话

我自己的体会是，主动型AI最大的门槛不是模型能力，而是工程化。很多团队花两周把demo跑通，却花两个月处理权限、审计、状态恢复这类脏活。这个比例在未来很长一段时间内都不会变，因为模型能力可以买，工程能力只能自己一点点磨。

如果你正准备做一个主动型AI项目，我给一个最朴实的建议：从“人工确认的自动建议”模式起步。先在只读场景里验证模型的规划能力和工具调用稳定性，比如自动生成巡检报告、自动分析日志、自动产出待办清单。等这些场景跑顺了，用户也开始信任了，再逐步开放“自动执行”权限。别一上来就做个完全自主的无人系统，那种系统大概率是给团队自己找麻烦。

还有一个小技巧：一定要给每一个主动动作设计“后悔药”。可以撤回的消息、可以回滚的变更、可以终止的任务，都要提前做好。因为再聪明的模型也会犯错，犯错不可怕，可怕的是没有兜底手段。把犯错成本设计得足够低，主动型AI才能真正从“演示项目”变成“生产工具”。