企业级 Agent 不是聊天机器人：从任务闭环设计架构

很多团队把 Agent 项目理解成“接一个大模型，再加一段提示词”。演示阶段确实可以这样做，但一旦任务涉及权限、业务系统和长期运行，问题就会迅速变成工程问题：模型什么时候可以决定下一步，工具失败后如何恢复，用户中途修改要求时怎样取消旧任务，哪些结果需要人工确认。

企业级 Agent 的核心不是让模型多说几句话，而是把一个业务目标变成可追踪、可恢复、可审计的任务闭环。模型负责处理不确定性，平台负责约束不确定性。

先定义任务，再选择 Agent 形态

不是所有场景都需要自由规划的 Agent。一个稳定的审批流、固定的报表生成流程，使用普通工作流更容易维护。只有当步骤、数据来源或工具选择会随输入变化时，才需要把部分决策交给模型。

可以先把场景按三个问题分类：

1. 下一步是否只有一个确定选择？如果是，优先使用工作流。
2. 是否需要根据上下文选择工具或补充问题？如果是，可以使用受约束的 Agent。
3. 是否允许任务持续运行并改变业务数据？如果是，必须增加状态机、权限和人工确认。

这一步可以避免把确定性逻辑放进提示词里。模型不应该决定订单状态如何流转，也不应该用自然语言表达权限边界。

一个可维护的分层架构

一个实用的企业级 Agent 通常包含以下层次：

层次	主要职责	关键产物
任务层	接收目标、拆分步骤、保存状态、处理取消和重试	Task、Step、状态机
推理层	模型路由、提示词、结构化输出、规划和反思	ModelRequest、Plan、Decision
工具层	访问搜索、数据库、业务 API 和文件系统	Tool Contract、Tool Result
上下文层	管理会话、检索证据、短期与长期记忆	Context、Evidence、Memory
治理层	身份、权限、预算、审计、内容与数据策略	Policy、Approval、Audit Event
运营层	追踪、评测、灰度、成本和故障处理	Trace、Metric、Incident

这些层次不一定对应六个微服务。早期可以放在一个应用中，但接口要分开。这样以后替换模型、迁移向量库或增加审批策略时，不需要重写整个 Agent。

用状态机承载任务，而不是依赖对话历史

对话历史适合帮助模型理解语境，不适合承担业务状态。建议为每个任务建立持久化状态，例如：

CREATED
  -> RUNNING
  -> WAITING_FOR_INPUT
  -> WAITING_FOR_APPROVAL
  -> SUCCEEDED
  -> FAILED
  -> CANCELED

每次工具调用都应记录输入摘要、调用者、策略结果、执行结果和下一步状态。任务恢复时根据最后一个已确认的 Step 继续，而不是把整段历史重新交给模型，让它猜测自己做到哪一步。

状态迁移也要有明确规则。WAITING_FOR_APPROVAL 不能被模型直接改成 SUCCEEDED；CANCELED 之后的迟到工具结果不能再次写入业务数据。把这些约束写在代码和数据库层，才不会因为提示词变化而失效。

模型负责判断，平台负责边界

模型路由不应只按“哪个模型最强”来做。可以按照任务类型选择模型：分类、抽取、改写等简单步骤使用低成本模型；需要复杂规划或跨材料推理的步骤使用更强模型；涉及高风险写入的步骤则要求结构化输出和额外校验。

模型输出最好先经过 schema 校验，再进入执行器。一个计划可以是：

{
  "goal": "核对客户合同中的付款条件",
  "steps": [
    {"id": "read_contract", "tool": "document.read", "args": {"document_id": "..."}},
    {"id": "compare_policy", "tool": "knowledge.search", "args": {"query": "付款条件"}},
    {"id": "draft_result", "tool": "result.compose", "depends_on": ["read_contract", "compare_policy"]}
  ]
}

执行器只接受允许的工具、参数类型和依赖关系。模型可以提出计划，但不能通过自由文本注入任意函数调用。

工具和记忆都要有边界

工具不是“给模型一个函数名”这么简单。工具描述需要包含输入 schema、权限要求、幂等规则、超时、重试方式和返回数据的敏感级别。读取合同和修改合同是两个不同能力，不能用一个 contract 工具覆盖。

记忆也应该分层：当前任务所需的上下文放在短期记忆，经过确认的用户偏好才进入长期记忆，临时推理过程不应默认永久保存。每一条长期记忆都需要来源、创建时间、适用范围和删除方式。否则记忆越多，冲突和过期信息越难排查。

企业场景必须把治理前置

至少需要提前设计以下控制点：

• 以用户和服务身份分别鉴权，不能只依赖前端传入的用户编号。
• 对读取和写入设置不同权限，批量写入设置更高风险等级。
• 为每个任务设置超时、最大步数、最大 token 和工具预算。
• 对敏感数据做脱敏、最小化传递和访问记录。
• 对付款、发布、删除、对外发送等动作设置审批或双人确认。
• 保存可关联到任务的审计记录，能够回答“谁在什么时候让 Agent 做了什么”。

治理不是上线前的文档工作，而是执行器的一部分。策略判断失败时应该安全拒绝，并告诉用户需要补充什么，而不是让模型继续猜。

从一个闭环开始扩展

企业级 Agent 适合从一条完整但范围较小的链路开始，例如“读取工单、检索知识、生成处理建议、人工确认后回写”。先把任务状态、工具契约、审计和评测跑通，再增加更多工具和自主规划能力。

每增加一个工具，都要增加对应的权限测试和失败测试；每替换一次模型，都要跑回归样本；每开放一个写入动作，都要重新检查审批和幂等性。这样 Agent 才会从一次演示，逐渐变成可以交付和维护的业务系统。

打赏