通用 Agent 不适合做企业 Agent
公司里用分析 Agent，除了答案本身，还要解决部署、权限、登录、协同和审计。
缺的不只是上下文
谈企业分析 Agent，上下文通常是第一个被提到的缺口：指标怎么算、口径归谁、规则写在哪。这个缺口确实存在。
但只有上下文还不够。模型之外还有一层运行框架，也就是 agent harness，负责装配上下文、调用工具、执行 SQL、校验权限、记录日志。
面向个人的框架服务的是单个使用者：围绕本机文件和个人凭据设计，出了问题也只能由本人发现、本人重跑。面向企业的框架要同时服务许多不同权限角色的人：同一条 SQL，分析师能跑、实习生不能；工具调用前先过权限；数据源按团队划分；每次调用都留痕。
上下文写得再好，缺这层框架，交付的多半是演示不错、上不了线的原型。
Web
分析师和业务人员不该为了问一个问题去装客户端、跟版本、处理升级失败。打开浏览器就能用，是这类工具能在公司推开的实际前提。
Web 之外还有两个附带效果。看板可以直接发链接，同事打开看到的是同一份数据；服务可以常驻，晚上在群里问的问题，早上有答案。
部署在公司内网
数据不出域通常是硬性要求。Agent 要能装在公司自己的机器上，连接内网数据源，使用内网能访问的模型出口。
这一条决定了数据在谁手上。装在个人设备上的方案，管理员既看不到，也没法约束。
模型接入集中，但不统一成一套配置
企业通常只有一个合规的模型出口，所以接入需要集中管理：供应商、密钥、可用模型清单由管理员维护，成员不用自己填。
但集中管理不等于全公司共用一个模型。团队任务不同，有人需要更强的推理，有人只需要响应快。比较实用的做法是管理员划定可用范围，成员在对话里自己选；标题生成、对话压缩这类后台任务再单独指定一个成本低的模型。
权限按项目划分
企业里没有「登录后可以看到全部数据」这回事。字段级隔离由数据库负责，工具层负责项目级隔离：谁能进入这个项目，以及他在项目里的角色。
接入公司统一登录
员工不应该为又一个工具记一套账号密码。接入公司现有的登录方式后，人员离职时权限随之收回，比事后清理账号可靠。
Cappy 支持 SSO 登录，企业也可以在此基础上接入自己的身份提供商。
接入公司协同工具
业务同事不会为了看一个数字打开一个新系统。把 Agent 接进飞书或 Slack，在群里问一句，答案和图表直接出现在对话里，需要细看再点进 Web。
可观测与审计
个人使用时，答案错了重问一次即可。公司里，一个错误的数字会被复制进周报、带进决策。所以调用要留得下记录：谁在什么时候问了什么、读了哪些上下文、跑了哪条 SQL、花了多少 token、结果有没有被标错。
这些记录不只是事后追溯，也是改进上下文的依据。反复答错的问题，通常说明少了一条指标定义。
小结
Cappy 按企业场景实现：Web 界面、内网部署、集中接入但成员可选模型、项目级权限、企业身份登录、飞书和 Slack 集成，以及完整的调用记录。