智能体定制
智能体定制是让 AI 在受控边界内读取上下文、调用工具、执行任务，并留下可审计记录。
在企业场景里，智能体不是一个会聊天的机器人，而是一个可以围绕目标进行判断、检索、调用系统、生成结果并等待人工确认的执行单元。它的价值来自“能做事”，风险也来自“能做事”，所以设计时必须同时考虑能力、权限和控制。
mermaid
flowchart TD
A["业务目标"] --> B["理解任务"]
B --> C["读取上下文"]
C --> D{"是否需要工具"}
D -- "需要" --> E["选择工具"]
E --> F["权限校验"]
F --> G["调用企业系统"]
G --> H["校验结果"]
D -- "不需要" --> H
H --> I{"是否高风险"}
I -- "是" --> J["人工确认"]
I -- "否" --> K["输出或执行"]
J --> K
K --> L["记录日志与反馈"]决策点
| 问题 | 判断 |
|---|---|
| 能调用什么工具 | 决定智能体的实际能力 |
| 能访问什么数据 | 决定权限和合规边界 |
| 是否需要人工确认 | 决定风险控制方式 |
| 如何记录日志 | 决定可追溯性 |
智能体通常适合什么任务
| 任务类型 | 示例 | 适合原因 |
|---|---|---|
| 多步骤信息处理 | 从客户资料、合同、邮件中整理摘要 | 需要理解上下文并按规则输出 |
| 系统协同 | 创建工单、查询库存、更新 CRM | 需要调用多个内部工具 |
| 流程辅助 | 审批前检查、资料补全、异常提醒 | 有明确规则和人工确认点 |
| 重复运营任务 | 生成周报、整理线索、跟进状态 | 高频、格式稳定、可记录 |
| 专家助手 | 法务、医药、投研、售前知识辅助 | 需要结合知识库和专业边界 |
权限设计
智能体的权限不能只放在提示词里。更可靠的做法是把权限放在系统层：
| 权限层 | 控制内容 |
|---|---|
| 用户身份 | 谁发起任务，属于哪个部门和角色 |
| 数据权限 | 能检索哪些知识库、文档和数据库记录 |
| 工具权限 | 能调用哪些 API、是否只读、是否可写入 |
| 动作权限 | 哪些操作必须人工确认 |
| 审计权限 | 谁可以查看调用记录和输出结果 |
失败处理
企业智能体必须考虑失败，而不是默认每次都成功。
| 失败类型 | 处理方式 |
|---|---|
| 缺少资料 | 明确说明缺少什么，不编造答案 |
| 工具调用失败 | 返回错误原因，支持重试或转人工 |
| 权限不足 | 提示无权限，不暴露敏感内容 |
| 结果不确定 | 降级为建议，不自动执行 |
| 高风险操作 | 进入人工确认或审批流程 |
FDE 如何设计智能体
FDE 会先从一个真实业务问题开始，拆出任务边界、数据来源、工具清单、成功标准和风险等级。然后把智能体放在 RAG 知识库、MCP、企业 API 和 LLMOps 之间，让它既能执行，也能被监控、评估和回滚。
常见误区
- 智能体不是权限系统，不能用提示词替代访问控制。
- 智能体越自主不一定越好，企业场景更需要可控执行。
- 先做复杂多智能体通常不是最优路径，先跑通一个高价值流程更重要。
- 没有日志和评估的智能体，很难进入生产环境。