AI Agent 工作台：让 agent 在业务系统内受控执行
企业 agent 不能只是会聊天，而要能在业务对象、工具、权限、审批和审计边界内执行任务。工作台的关键是受控执行，而不是万能权限。
先给结论：企业 Agent 的关键不是聪明，而是能不能受控执行——把对象、工具、权限、审批和审计做成元数据，Agent 才能在边界内真正办事，而不只是会聊天。
很多企业已经有了 AI 聊天入口，但真正的问题很快会出现：聊完以后，业务还是要人去系统里操作。
用户问“哪些客户有续约风险”，AI 能回答；但要创建跟进任务，还要切 CRM。用户问“这份合同有哪些风险”，AI 能总结；但要发起审批，还要去合同系统。用户问“哪些工单快超时”，AI 能列出来；但要转派、升级、通知负责人，还要人工处理。
所以企业下一步需要的，不只是聊天助手，而是可执行任务的 AI 工作台。
它不是让 Agent 拿到管理员权限到处乱跑，而是把业务对象、工具、权限、审批和审计放在同一个运行边界里。
你可以对平台说：
帮我搭建一个 AI Agent 业务执行工作台。它可以查询客户、商机、工单、合同、任务和审批；用户用自然语言提出目标后，Agent 可以生成计划、调用受控工具、创建任务、发起审批、生成报告；高风险动作必须人工确认，所有读取和执行都要审计。
这句话生成的，是一个能把自然语言意图转成受控业务动作的应用。
Agent 的关键不是聪明，而是能不能受控执行
企业对 Agent 的期待很高：它要会查数据、会分析、会生成、会调用工具、会推动流程。
但企业真正担心的是另一面：
- 它能看到哪些数据？
- 它能不能越权查询？
- 它能不能直接改业务记录？
- 它执行错了怎么办？
- 谁批准了高风险动作？
- 审计里能不能复盘它做过什么？
所以企业 Agent 的核心不是“模型有多聪明”，而是“它能不能在业务系统的边界里执行”。
这要求 Agent 工作台必须元数据驱动。业务对象定义它能理解什么，工具定义它能做什么，权限定义它能代表谁做，审批定义哪些动作要确认，审计定义事后如何追踪。
用自然语言生成 Agent 工作台
第一轮搭建时，平台应该生成这些对象和能力：
| 元数据 | 作用 |
|---|---|
business_object | 客户、工单、合同、任务等可查询对象 |
agent_tool | 查询、创建、更新、发起审批、生成报告等工具 |
tool_permission | 哪些角色可以调用哪些工具 |
execution_plan | Agent 对任务的分解步骤和待确认动作 |
approval_gate | 高风险动作的人工确认和审批节点 |
agent_run | 每次 Agent 运行的输入、计划、工具调用和结果 |
audit_event | 数据读取、建议、确认、执行和失败记录 |
有了这些元数据，用户说：
找出本周快超时的企业客户工单，并给负责人创建跟进任务。
Agent 不会直接凭空执行。它应该先：
- 检查用户是否有权限查看企业客户工单；
- 调用工单查询工具；
- 生成候选工单列表；
- 说明将创建哪些任务；
- 请求用户确认；
- 调用任务创建工具；
- 写入审计记录。
这才是企业可接受的 Agent 执行方式。
搭建后用语言定义工具和边界
Agent 工作台的能力会逐步扩大。管理员可以说：
让销售主管可以批量创建商机跟进任务，但不能修改商机金额和合同条款。
平台应生成工具权限：允许创建任务，禁止修改金额和合同。
合规负责人可以说：
所有涉及客户数据导出的动作，都必须审批，并记录导出字段和原因。
这会生成审批门和审计字段。
业务负责人可能说：
Agent 可以自动关闭重复工单，但关闭前必须把重复依据发给客服确认。
这会生成一个半自动动作：AI 判断重复，人确认关闭。
自然语言搭建让企业可以逐步扩大 Agent 能力，同时持续维护边界。
用户如何用 Agent 工作台工作
一个业务用户可以直接说：
帮我准备明天客户经营会，列出续约风险最高的 10 个客户，并生成每个客户的行动建议。
Agent 应该跨对象工作：客户、合同、工单、商机、任务、回款和使用记录。它生成报告，但不会自动对客户发消息。
销售主管可以继续说：
给每个客户负责人创建一个跟进任务，要求本周五前更新计划。
这时 Agent 应生成执行计划，展示任务列表，等待确认后创建。
法务负责人可以说：
找出本月所有包含非标付款条款的合同，按风险排序，并发起复核流程。
Agent 查询合同条款对象，生成风险列表，发起复核审批，并记录工具调用。
这个工作台的价值，是把“问 AI”推进到“让 AI 帮我做一部分事”，但每一步都受控。
哪些动作可以自动，哪些必须确认
企业 Agent 最重要的设计，是动作分级。
低风险动作可以更自动：
- 生成摘要；
- 查询列表；
- 创建个人待办草稿；
- 汇总报告；
- 标记候选风险；
- 发送内部提醒草稿。
中风险动作需要用户确认：
- 创建任务；
- 更新状态；
- 批量分派；
- 合并记录；
- 发起审批；
- 发送内部通知。
高风险动作需要审批：
- 修改金额、合同、权限和主数据；
- 对外发送承诺；
- 批量导出客户数据；
- 关闭合规或审计问题；
- 执行付款、退款或资源释放。
这不是保守，而是让 Agent 可以从辅助走向执行的必要条件。
第一版怎么搭
Agent 工作台不应该一开始覆盖所有系统。更好的路径是从一个业务域开始。
第一，选择一个对象边界清楚的场景，比如工单、CRM、合同或项目。
第二，定义 Agent 可查询对象和只读工具，先做分析和总结。
第三，增加低风险写入工具，比如创建任务、生成报告、发起提醒。
第四，为中高风险动作配置确认和审批。
第五，完善 agent_run 和审计日志，让每次执行都能复盘。
第六，逐步跨系统扩展，把多个业务对象连接成更完整的执行工作台。
这条路径让企业可以先验证价值，再扩大 Agent 的权限。
ObjectStack 的价值：把 Agent 放进业务运行时
很多 Agent 演示看起来很强，但一到企业生产环境就卡住，因为它们没有对象、权限、流程和审计边界。
ObjectStack 的元数据驱动能力，让业务系统天然可以暴露成受控工具：对象定义数据语义，权限定义访问范围，流程定义动作路径，审批定义人工关口，审计记录每一次 Agent 行为。
用自然语言搭建 Agent 工作台，本质上不是生成一个聊天机器人，而是生成一个业务执行层。
企业真正需要的 Agent，不是替人绕过系统，而是在系统之上帮助人更快地理解、计划、确认和执行。它要能做事，也要知道什么时候停下来等人批准。