常驻式AI智能体的架构设计与落地实践

一、从即时问答走向持续任务执行

传统对话式人工智能通常采用“用户提问—模型回答”的同步交互模式。一次请求结束后，系统不会主动维护任务进度，也不会在后台持续采取行动。这种模式适合知识问答、内容生成和简单分析，却难以处理需要数小时、数天甚至更长时间才能完成的复杂目标。

常驻式AI智能体则面向另一类问题：用户只描述最终目标、约束条件和授权范围，系统负责拆解任务、调用可用资源、记录中间状态，并根据外部事件持续推进。例如：

• 定期收集业务指标并生成异常分析；
• 跟踪项目里程碑，识别延期风险；
• 根据告警信息整理排障上下文；
• 持续检查文档、代码和配置之间的一致性；
• 汇总客户反馈并形成结构化问题清单；
• 在满足预设条件后发起审批，而不是直接执行高风险操作。

因此，常驻式智能体的核心并不是“让模型一直运行”，而是建立一个可暂停、可恢复、可审计、可授权的长期任务系统。大语言模型主要承担目标理解、任务规划和非结构化信息处理，真正保证系统稳定性的仍然是任务调度、状态管理、权限控制和异常恢复等工程机制。

二、常驻式智能体的能力边界

一个完整的常驻式智能体通常需要具备以下能力。

1. 目标理解与约束识别

用户给出的往往是业务目标，而不是可直接执行的技术指令。例如，“持续关注核心接口稳定性，并在风险扩大前通知负责人”包含多个隐含问题：

• 哪些接口属于核心接口；
• 稳定性由哪些指标衡量；
• 什么情况可以定义为风险；
• 通知哪些人员；
• 智能体可以读取哪些数据；
• 是否允许自动调整配置；
• 哪些操作必须经过审批。

系统不能仅根据自然语言自行推断全部边界，而应把目标转换为结构化任务定义，至少包含目标、输入来源、完成条件、禁止事项、授权范围、通知方式和人工介入规则。

2. 任务规划与动态调整

长期目标通常无法通过单次模型调用完成。智能体需要把目标拆分为多个步骤，并明确步骤之间的依赖关系。例如：

1. 获取监控指标；
2. 检查数据完整性；
3. 与历史基线进行比较；
4. 判断异常是否持续；
5. 收集相关变更记录；
6. 生成初步原因分析；
7. 根据风险等级通知用户或申请进一步授权。

初始计划也不应被视为不可变流程。当数据缺失、资源不可用或业务优先级发生变化时，智能体需要重新规划。不过，重新规划不能绕过原有权限边界，也不能擅自扩大任务范围。

3. 后台持续推进

“常驻”不等于持续占用计算资源。合理方式是采用事件驱动或调度驱动机制：没有新事件时，任务进入等待状态；定时条件满足、外部数据变化或用户完成审批后，任务才会继续运行。

这种设计可以降低资源浪费，也有利于控制重复调用和无限循环。常见触发源包括：

• 定时调度；
• 消息事件；
• 数据状态变化；
• 监控告警；
• 用户补充信息；
• 审批结果；
• 子任务完成通知。

4. 主动请求人工介入

智能体不应把所有无法完成的情况都归类为失败。很多时候，正确行为是暂停并请求用户提供信息或授权。例如：

• 任务目标存在歧义；
• 所需数据不在当前可访问范围内；
• 即将执行不可逆操作；
• 多个方案的业务影响无法由系统判断；
• 预测结果置信度不足；
• 实际执行成本超过预设预算。

高质量的人工介入请求应说明当前进展、阻塞原因、可选方案、各方案影响以及需要用户作出的具体决定，而不是仅返回“任务无法完成”。

三、总体系统架构

常驻式智能体可以划分为控制层、认知层、执行层、状态层和治理层。

1. 控制层

控制层负责管理任务生命周期，包括创建、排队、运行、暂停、恢复、取消和归档。它不依赖模型自由决定任务是否继续，而是依据确定性的状态规则进行调度。

典型任务状态可以设计为：

CREATED       已创建
PLANNING      规划中
READY         等待执行
RUNNING       执行中
WAITING       等待外部事件
NEED_INPUT    等待用户补充信息
NEED_APPROVAL 等待审批
RETRYING      异常重试
COMPLETED     已完成
FAILED        执行失败
CANCELLED     已取消

每次状态切换都应记录触发原因、操作者、时间、输入摘要和输出摘要，以便后续审计。

2. 认知层

认知层负责理解目标、生成计划、分析非结构化内容和选择下一步行动。为了降低模型输出不稳定带来的风险，认知层的结果应尽量结构化，例如：

下一步动作：
- 动作类型：读取数据
- 目标资源：业务指标集合
- 必要权限：只读
- 预期输出：最近一个统计周期的指标摘要
- 失败处理：重试两次后请求人工确认数据源
- 风险等级：低

模型可以提出动作建议，但动作能否执行必须由控制层和治理层共同判断。对于权限校验、参数合法性和风险分级等关键逻辑，应优先使用确定性程序，而不是完全依赖自然语言判断。

3. 执行层

执行层负责调用数据库、对象存储、消息队列、日志服务、监控系统和内部业务接口等资源。每一种执行能力都应通过受控适配器暴露，避免智能体直接访问底层系统。

适配器应至少包含以下约束：

• 明确的输入与输出格式；
• 调用超时；
• 最大重试次数；
• 幂等标识；
• 权限校验；
• 敏感字段过滤；
• 操作风险等级；
• 审计日志；
• 模拟执行或预检查能力。

对于写入、删除、发布和权限变更等高风险动作，可以采用“生成执行方案—预检查—人工审批—实际执行”的多阶段流程。

4. 状态层

长期任务不能只依赖对话上下文。随着任务持续推进，对话内容会快速增长，并造成成本上升、信息冲突和关键事实丢失。状态层需要区分不同类型的信息：

• 目标状态：任务最终要达到什么结果；
• 计划状态：当前步骤、依赖关系与优先级；
• 执行状态：已执行动作及结果；
• 事实状态：经过验证的业务事实；
• 临时上下文：当前步骤所需的短期信息；
• 用户偏好：通知频率、输出格式等非敏感偏好；
• 权限快照：任务创建和执行时的授权情况。

系统应定期生成任务检查点。发生故障后，可以从最近一次检查点恢复，而不是重新执行全部步骤。

5. 治理层

治理层贯穿所有模块，主要负责身份认证、授权、数据隔离、风险控制、预算限制和审计。企业环境中尤其需要避免智能体把“能够访问”误解为“可以随意使用”。

权限模型应同时考虑：

• 用户本人具有什么权限；
• 用户是否明确委托智能体使用该权限；
• 当前任务是否需要该权限；
• 授权是否已经过期；
• 操作是否需要二次确认；
• 资源是否包含敏感数据；
• 操作结果是否会影响其他用户或生产环境。

四、任务循环的工程实现

一个安全的执行循环可以抽象为以下伪代码：

while task.is_active():
    state = load_checkpoint(task.id)
    if state.wait_condition_not_met():
        sleep_until_event()
        continue
    context = build_minimal_context(state)
    proposal = planner.propose_next_action(context)
    validation = policy_engine.validate(
        action=proposal,
        permissions=state.permissions,
        budget=state.remaining_budget,
        risk_rules=state.risk_rules
    )
    if validation.need_user_input:
        save_checkpoint(state)
        request_user_input(validation.reason)
        pause_task()
        continue
    if validation.need_approval:
        save_checkpoint(state)
        create_approval_request(proposal)
        pause_task()
        continue
    if not validation.allowed:
        record_rejection(validation.reason)
        replan_or_fail()
        continue
    result = executor.run_with_idempotency(proposal)
    update_state(state, result)
    save_checkpoint(state)
    if completion_checker.is_done(state):
        finish_task()

该循环体现了几个关键原则。

第一，规划和执行分离。模型提出下一步动作，但不能绕过策略检查直接执行。

第二，任何外部操作前都要保存必要状态。即使进程中断，也能判断动作是否已经发生。

第三，使用幂等标识处理重复执行问题。网络超时并不代表操作未成功，如果直接重试，可能造成重复通知、重复写入或重复提交。

第四，把人工确认设计为正常状态，而不是异常分支。这样任务能够在用户响应后继续运行。

五、可靠性与异常恢复

长期任务会面对比即时问答更多的不确定性，包括服务重启、网络波动、接口限流、数据延迟和权限变更。工程设计需要重点处理以下问题。

1. 幂等性

每个可能产生副作用的动作都应携带唯一执行标识。执行层需要记录该标识及其结果。如果同一动作被重复提交，系统应返回已有结果，而不是再次产生副作用。

2. 超时与重试

并非所有错误都适合重试。临时网络故障可以采用带退避的有限重试；参数错误、权限不足和资源不存在通常应直接进入重新规划或人工介入流程。无限重试会浪费资源，还可能放大故障。

3. 检查点与恢复

检查点应记录当前任务阶段、已完成动作、待处理事件和必要上下文。恢复时需要先核对外部系统中的实际结果，不能只依赖本地记录。例如，本地记录显示请求超时，但外部操作可能已经成功。

4. 并发控制

同一任务可能被定时事件、用户操作和外部消息同时唤醒。系统需要使用任务租约、版本号或条件更新等机制，保证同一时刻只有一个执行者能够推进关键状态，防止重复执行和状态覆盖。

5. 终止条件

智能体必须具备明确的停止条件，包括目标完成、用户取消、预算耗尽、授权过期、连续失败超过阈值以及任务超过最长存续时间。缺少终止条件的后台智能体容易形成无效循环。

六、权限、安全与数据保护

常驻智能体通常比普通聊天应用拥有更多外部访问能力，因此安全设计必须前置。

首先，应遵循最小权限原则。任务只获得完成当前目标所需的最低权限，读取和写入权限应分开授予。

其次，授权应具备时间范围和资源范围。例如，只允许在指定时间内读取某一类业务数据，而不是长期访问全部数据。

再次，高风险动作需要分级治理。只读查询通常可以自动执行；对外发送信息、修改配置、删除数据和变更权限则应设置更严格的审批流程。

此外，提交给模型的上下文应进行最小化处理。与当前决策无关的个人信息、密钥、完整日志和敏感业务数据不应进入模型上下文。日志中也应进行脱敏，避免审计系统成为新的数据泄露入口。

对抗提示注入同样重要。智能体从文档、网页内容或消息中读取到的文本只能被视为外部数据，不能自动升级为系统指令。系统应区分可信控制指令与不可信业务内容，禁止外部文本擅自修改权限和任务目标。

七、可观测性与质量评估

仅监控模型调用是否成功，无法判断常驻任务是否健康。建议从四个层面建立指标。

1. 任务层

关注任务完成率、平均持续时间、暂停时长、取消率和超期任务数量。长期处于运行状态但没有有效进展的任务，应被识别为停滞任务。

2. 步骤层

记录每一步的输入摘要、输出摘要、耗时、重试次数、依赖资源和状态变化。这样才能定位任务究竟阻塞在规划、权限校验还是外部执行环节。

3. 决策层

评估计划是否合理、是否频繁反复、是否出现无效调用，以及人工修改计划的比例。对于关键决策，可保存模型建议、规则判断和最终执行动作之间的对应关系。

4. 业务结果层

最终评价标准不应只是回答流畅度，而应是目标是否达成。例如异常发现是否及时、报告是否可用、人工处理时间是否减少，以及误操作是否得到控制。

在上线前，可以使用历史任务进行离线回放，让智能体在不产生真实副作用的环境中执行，并检查其计划、权限申请和停止条件是否合理。高风险场景还应采用影子运行：系统生成建议但不实际执行，再由人工结果验证其可靠性。

八、适合与不适合的应用场景

常驻式智能体适合目标明确、步骤较多、需要持续观察且允许阶段性人工介入的任务。例如运营数据巡检、研发流程跟踪、知识库维护、告警信息归纳和周期性合规检查。

它不适合缺少明确责任主体、错误成本极高且无法回滚的任务，也不适合将所有决策责任完全交给模型的场景。如果任务涉及资金、权限、生产配置或外部承诺，智能体更适合作为分析与流程协调者，而不是不受约束的最终决策者。

九、落地实施建议

企业可以从低风险、只读型任务开始，逐步扩大能力范围。

第一阶段，智能体只收集信息并生成建议，不执行任何外部写入操作。重点验证任务拆解、状态保存和结果质量。

第二阶段，开放低风险动作，例如创建内部待办、生成报告草稿和发送受控通知，同时建立幂等与审计机制。

第三阶段，在审批流程保护下开放有限写入能力，并对授权时效、预算和操作范围进行严格限制。

第四阶段，再根据历史数据评估哪些审批可以规则化自动通过。自动化范围应由稳定的证据逐步扩大，而不是在初始阶段一次性开放。

十、总结

常驻式AI智能体代表了人工智能应用从“生成答案”向“持续完成目标”的转变。真正决定其可用性的，不只是模型的推理能力，还包括任务状态机、事件调度、权限治理、幂等执行、故障恢复和全链路审计。

在设计此类系统时，应始终坚持三个原则：模型负责提出建议，确定性系统负责控制执行；权限范围必须显式、最小且可撤销；任何长期任务都必须可暂停、可解释、可恢复和可终止。只有把自主性建立在清晰的工程边界之内，常驻式智能体才能成为可靠的生产力工具，而不是不可预测的后台进程。