演示里的 Agent 很容易让人兴奋：一句话，它就能搜索、写作、做表格、调用工具。把它接进公司以后，问题马上换了。它可以看客户合同吗？可以给客户发邮件吗？写错以后谁负责停下来？

在问“会不会做”之前，先回答“能不能做”

业务任务从来不只有目标。它还有责任人、时限、成本、例外和不能碰的地方。员工通过长期协作记住了这些边界，Agent 没有这种默契。

假设让 Agent 跟进一条海外销售线索。它需要读懂客户来自哪个市场、看过哪些产品、上次沟通说了什么。它也许可以起草邮件，但折扣承诺、合同条款和正式发送应由指定成员确认。少了这层区分，“自动跟进”就可能变成自动制造麻烦。

Agent 的可靠性，不只看答案对不对，还要看它是否在被允许的时间，用被允许的资料，做了被允许的动作。

上下文不是把更多文档塞进去

很多团队解决上下文问题的方法，是把知识库越建越大。资料确实多了，Agent 却更难判断哪一份适用于当前任务。上下文的重点不是数量，而是相关性和时效。

一项任务需要的上下文可以整理成四类：

  • 角色。 谁发起任务，谁对结果负责，Agent 此刻代表哪个岗位。
  • 对象。 当前客户、商品、项目或内容是什么，状态走到了哪里。
  • 规则。 交付标准、品牌表达、预算上限、合规要求和禁止事项。
  • 历史。 过去做过什么，人改过什么，上一轮为什么没有通过。

每次只取与当前任务有关的部分。上下文越精准，越容易检查 Agent 为什么做出某个判断。

权限应按动作分级

“允许使用 CRM”这样的权限太粗。查看客户列表、修改联系人、导出全部数据和向客户发送消息，风险完全不同。Agent 权限最好跟动作绑定，而不是跟软件名称绑定。

  1. 读取。 允许查看完成任务所需的字段，默认不开放整库导出。
  2. 草拟。 可以生成建议、文案或待办，但不改变外部状态。
  3. 内部写入。 更新标签、补充记录、创建任务，过程保留日志。
  4. 外部执行。 发送、发布、付款、改价等动作，单独授权并设置审批。

权限还应有时间和范围。例如只允许处理本周新进入的线索，或只在某个项目空间里更新资料。范围越清楚，出错后的影响越有限。

权限设计的实用原则先让 Agent 提建议，再开放内部写入，最后才考虑外部执行。每升一级，都用真实任务记录判断它是否稳定。

人工确认不该成为形式

人在环不等于每一步都点“同意”。如果员工要逐字检查 Agent 的所有输出，自动化没有减轻工作；如果高风险动作也一路自动通过，确认按钮只是装饰。

适合停下来确认的，通常是不可轻易撤回的动作：对外发布、费用支出、权限变更、合同承诺，以及明显偏离历史范围的决定。系统应该把 Agent 使用的资料、准备执行的动作和可能影响放在同一个确认界面里，让人能快速判断。

InFlow X 的任务台账会记录输入、工具调用、审批和结果。发生问题时，团队可以找到具体一步，而不是只看到一句“Agent 执行失败”。人工修订也会回到后续任务，避免同一种错误重复出现。

让 Agent 进入业务，不是给它一个万能账号。是给它一份明确的工作、一包刚好够用的上下文，以及一组随风险变化的权限。