很多小微企业把同一个企业智能体挂在企业微信、飞书或者自建网页里，全员都用一个入口。短期看是省事，问题很快就会出现：销售小王上午让 Agent 帮他查了某客户的合同金额，下午客服小李进来问一个完全不相关的问题，Agent 却把上一轮的合同上下文带了出来。更糟的是，小李意外触发了一个本来只该对小王开放的工具，把本不该外发的一条财务草稿推到了群里。
这种问题不是工具不稳定，而是把会话和权限当成同一个东西在用。多人共用入口时，会话上下文是按人隔离还是按项目隔离、工具和数据是按人隔离还是按角色隔离、谁能看到上一轮的痕迹，需要先想清楚，再让 Agent 去执行。
先把会话上下文和工具权限分开看。会话上下文是 Agent 在这一轮对话里看到的历史、文件和记忆；工具权限是 Agent 在这一轮里被允许调用什么函数、读什么数据、写什么系统。两层都要做最小授权，不要图省事只设一道闸门。上下文只看当前用户授权看到的那一段历史，工具和数据只对当前用户所属的最小角色开放。
再看隔离的颗粒度。最轻的做法是按用户隔离：每个员工进入入口时带自己的工号或账号，Agent 内部维护一个 user_id 维度的会话列表，不同 user_id 之间不共享任何上下文、任何文件记忆、任何工具调用结果。这种方式实现简单，能解决大多数串台问题。再细一层是按项目隔离：同一员工可能在多个项目里切换，每次进入一个新的项目就开一条独立会话，老项目的上下文不会带进新项目。最严的是按任务隔离：每一个具体任务单独起一段会话，用完即销毁，这种方式适合敏感程度高的场景，例如财务和法务相关的工作。
做最小可行的实施时，有四件事可以在一天内完成。第一，给入口加上统一的身份识别，例如要求用户首次进入时绑定企业邮箱或手机号，并在每次请求里带上这个标识。第二，把工具调用和数据读取从代码里抽到一份权限清单，按角色分组，谁都不能越过自己的清单。第三，会话上下文只在当前用户和当前项目下保留，不要做全员共享记忆；如果某个结论确实需要跨人共享，把它写成知识库文档而不是会话记忆。第四，给每一次工具调用加上审计日志，保留调用人、调用时间、参数和返回内容；这条日志不要进入 Agent 自己的上下文，只在管理员后台查看。
边界同样要明确。两个反例不要做：一是把管理员万能账号直接交给一线员工使用，结果所有数据其实对全员可见；二是为了图方便把所有工具的权限都默认开放，只在出问题时再关。会话上下文的清理也要避免一刀切，正确做法是按 user_id 加 project_id 做软隔离，既不会串台，又不丢上下文。
如果目前已经出现了串台，第一步先复盘最近一次事故，看是上下文串了还是权限串了。上下文串台的修复成本低，只要把上下文按 user_id 隔离一次就能立竿见影。权限串台要先收回越权账号的入口，再补权限清单和审计日志，否则同样的事故会在下一周重复出现。
多员工共用一个企业智能体入口，不是技术难点，而是设计问题。先把按人、按项目、按任务三种颗粒度选清楚，再用权限清单和审计日志守住边界，会话上下文自然就不会再串台。