OpenAI 在一份经济研究材料里，把 agent 的工作单位说得很清楚。它处理的已经不只是一次问答，而是可以持续几分钟到几小时的委托任务，会调用工具、接触环境、反复改结果。企业软件团队看到这里，别急着把所有流程都交出去。
真正要补的是交接点。
材料里提到，OpenAI 内部不只工程部门在用 Codex，法律、招聘这类非技术部门也把它放进工作流。这个信号挺明确，agent 已经从开发辅助走向跨部门协作。跨部门之后，问题会变得很具体，谁能发起任务，谁能看上下文，谁批准外发，谁处理失败。
长任务比单次问答更难管
聊天机器人答错一句话，用户通常能当场发现。agent 跑一个长任务，风险会藏在中间步骤里。它可能查了旧资料，调用了不该调用的工具，或者在没有确认的情况下把草稿发进业务系统。等人看到结果，现场已经被改过了。
我更愿意把 agent 当成一个临时同事来管。能读哪些资料，能写哪些系统，遇到不确定内容要停在哪一步，这些规则要写在平台里，不能靠提示词硬撑。
权限要按动作拆开
企业做 AI 应用时，经常只问用户能不能使用某个 agent。这个粒度太粗。一个销售线索 agent 至少有读取 CRM、整理会议纪要、生成跟进邮件、写回客户状态几类动作。读取和写回的风险不在一个层面。
更稳的办法是分层授权。读取内部知识库是一档，生成草稿是一档，写回业务系统又是一档。涉及客户邮件、合同字段、财务数据时，让 agent 先给草稿和理由，人工点确认后再执行。别嫌麻烦，企业系统里最贵的事故往往来自一个顺手点开的自动化。
交接记录要能复盘
长任务失败后，团队不能只看最终输出。排查时要知道 agent 用了哪个版本，拿到了哪些文件，调用了哪些工具，在哪个步骤转向了错误判断。缺一段记录，复盘就会变成凭感觉吵架。
优易云做企业流程系统时，会把这类记录放进任务流。一个 agent 触发了审批，后台要保留发起人、业务对象、上下文来源、执行动作和人工确认。以后换模型、换工具、换流程，团队也知道问题出在什么地方。
先让 agent 做可撤回的事
很多团队会被长任务能力吸引，直接把它接到核心系统。这个节奏有点急。更合适的起点是资料汇总、工单归类、会议纪要整理、需求拆分、日志初筛这些流程。它们费时间，有明确输入输出，出错后也容易改回来。
等团队把权限、审批、日志、回滚跑顺，再让 agent 写入 CRM、创建工单、更新项目状态。一步一步来，别把试点做成线上事故演练。
真正的门槛在管理面
OpenAI 的材料把趋势讲得很清楚，agent 会承担更长、更复杂、更跨职能的任务。落到企业软件里，模型能力只是一部分。目录、权限、审计、审批、版本管理，这些老东西又回来了，而且比以前更要紧。
工程团队可以从一个小清单开始。每个 agent 要有负责人、适用范围、可调用工具、敏感动作、失败处理和停用开关。清单不酷，但它能救命。
