销售团队最缺的不是另一个 AI，而是有人把跟进这件事一直做下去
销售有一种工作特别奇怪：真正决定成交的事情可能只占一天的一小部分，但大量时间都花在了“别忘了”。
客户昨天回了邮件，要记得今天跟；会议结束后要补 CRM；新线索进来要判断优先级；销售群里问了一句产品参数，还得去文档里翻答案；月底做复盘，又要从 CRM、表格和聊天记录里重新整理一遍。
这些事情并不难，甚至很多只需要几分钟，但它们会不断把注意力从真正重要的客户沟通里拉走。
所以很多团队第一次接触 AI，会从“帮销售写邮件”开始。
这当然有用，但我们觉得还不够。
如果 AI 只是帮你把一封邮件写得更快，工作方式其实没有改变。真正值得做的，是让 Agent 接住邮件之后的查询、判断、记录和下一步动作。
ZGI 更适合做的，恰恰是后面这一段。
为什么不是再买一个销售 AI SaaS
现在市面上的销售 AI 工具已经很多，有的做邮件生成，有的做会议纪要，有的做线索评分。
如果公司的需求非常标准，直接采购成熟 SaaS 往往是最快的。
但不少团队真正开始用以后，会遇到另一个问题：自己的流程并不标准。
A 公司可能要求销售邮件回复后先查 CRM，再结合历史订单判断客户等级；B 公司可能需要查询产品知识库；C 公司还要调用内部报价系统。最后真正有价值的，不是一个独立的 AI 功能，而是如何把公司原来的系统和业务规则串起来。
这也是 ZGI 的定位更偏 Agent Runtime 的原因。
它不是只提供一个聊天窗口，而是把模型、知识库、业务数据、Skills 和 Workflow 放在同一个运行环境中，让团队可以按自己的销售流程去搭 Agent。
ZGI 同时开放源代码并支持自托管。如果企业需要把 CRM、内部知识库或者数据库接进来，也可以把整套运行环境放在自己的基础设施里。
需要说明的是，ZGI 当前采用 ZGI Community License。个人、研究、教育及组织内部使用可以免费；托管式多租户、白标等商业模式需要按照许可获得商业授权。对于内部销售自动化场景，它更接近一套可以自己掌握的企业 AI 底座，而不是只能使用固定功能的 SaaS。
场景一：客户回邮件以后，不再只弹一个通知
先从一个最常见的动作开始。
客户回复邮件以后，传统流程通常是销售自己打开邮件、判断意向、去 CRM 查客户背景，再决定下一步。
真正进入 Agent Workflow 后，可以把这段流程拆开。
第一步，Agent 读取邮件内容，判断这是询价、产品咨询、明确采购意向，还是普通跟进。
第二步，调用 CRM 或数据库查询客户的历史沟通、公司信息和过去的机会记录。
第三步，根据团队自己的销售规则进行分流。例如高潜客户通知负责人，已有订单客户进入售后或续费路径，一般咨询先调用产品知识库生成建议回复。
最后，真正涉及价格、合同承诺或者特殊商务条款时，再把任务交给销售确认。
这里最重要的不是“AI 会不会判断客户意向”。
模型早就能做这件事。
真正的价值在于：判断之后的工作，可以继续往下走。
这就是 Workflow 和 Skills 的意义。模型负责理解，知识和数据提供上下文，Skill 负责调用真实系统，Workflow 决定什么情况下继续、暂停或者转给人。
概念示意：Agent 整理上下文并准备跟进材料，销售人员确认关键沟通。
场景二：产品问题，不要让销售每天在群里问同一遍
销售团队另一个很典型的场景，是产品知识散落在不同地方。
价格政策在一个表格里，技术参数在产品手册里，交付周期在另一个系统里，常见问题又藏在销售群历史聊天记录里。
所以客户问一句：
“这个型号支不支持某种接口？”
销售第一反应不是回答，而是找人。
这种问题很适合先做一个内部知识 Agent。
在 ZGI 中，可以把产品文档、FAQ、销售政策、培训资料等放进企业知识库。销售直接提问，Agent 基于内部资料检索并生成答案。
但我们不建议把它做成一个只会“搜索文档”的机器人。
更进一步，可以让它在需要的时候调用数据库或者内部接口。例如库存、订单进度、价格等实时数据，不应该被写死在知识库里，而应该在用户提问时实时查询。
于是同一个入口可以同时回答：
“这个产品的主要参数是什么？”
也可以继续处理：
“现在还有没有库存？”
前者来自知识库，后者来自业务数据。
这也是 ZGI 把 RAG、数据库和 Skills 放在一起的原因。企业真正需要的知识，本来就不只存在 PDF 里。
场景三：销售日报，不应该每天重新做一次
不少销售团队每天仍然在做一件非常“2020 年”的事情：从 CRM 导数据、复制到 Excel、整理几个指标，再写一段总结发到群里。
AI 很适合吃掉这里面的机械劳动。
在 ZGI 的 Workflow 中，可以设置固定流程：读取销售数据，计算新增线索、跟进率、成交情况等指标，再调用模型分析异常和变化，最后输出一份统一格式的日报或周报。
如果团队有固定报告模板，还可以通过 Skill 生成文件或者图表。
这里有一个很重要的区别。
普通 AI 是：
“把这份数据发给我，我帮你分析。”
Workflow 是：
“这件事情以后按照这个规则执行。”
后者才是真正的自动化。
场景四：把优秀销售的经验做成 Skill
很多团队真正稀缺的不是话术，而是判断方法。
什么样的客户应该马上跟？
什么情况下应该停止追？
什么问题需要售前介入？
什么需求看起来很大，但实际上成交概率很低？
这些过去都存在优秀销售的脑子里。
现在可以尝试把其中明确、可复用的一部分整理成 Skill。
例如做一个“线索评估 Skill”，明确需要查看的字段、评分原则、风险信号和输出格式；再做一个“销售邮件 Skill”，规定不同阶段客户应该如何回复、哪些承诺不能由 Agent 自动给出。
模型可以换，但这些企业自己的销售方法应该留下来。
我们认为这才是 Skills 在企业里的长期价值：不是给 AI 多装几个功能，而是把组织自己的经验逐渐变成可以复用的能力。
这套方案不能做什么
销售场景很容易让人对 Agent 产生过高期待，所以有几件事必须提前说清楚。
Agent 不应该自动承诺价格、合同条件和交付日期，除非企业已经给出了非常明确的规则和权限边界。对于战略客户、异常商务条件和高风险决策，人仍然应该处在流程里。
模型判断客户意向也不会百分之百准确，所以更适合做筛选和辅助，而不是直接决定一个客户“值不值得跟”。
如果公司的 CRM 数据本身非常乱，Agent 也不会自动把脏数据变好。AI 能放大好的流程，也能放大原本混乱的流程。
所以我们更建议先选一个边界明确的任务开始，例如内部知识问答、线索分类或者固定日报，然后再逐渐扩大自动化范围。
为什么我们觉得开放源代码在这里很重要
销售 Agent 一旦真正跑起来，它接触的已经不是公开信息。
客户名称、联系方式、订单、报价、历史沟通，这些都属于企业内部数据。
所以企业最终一定会关心：数据在哪里？调用了什么模型？执行记录有没有保留？能不能部署在自己的环境里？
ZGI 开放源代码和支持自托管，本质上解决的是这部分控制权问题。
团队可以自己选择模型、连接自己的数据库和业务系统，也可以围绕自身流程继续扩展 Skills 和 Workflow。
我们不觉得所有企业都应该自己造一套 AI 系统。
如果一个成熟 SaaS 已经完全满足需求，直接购买往往更有效率。
但如果你的业务真正特殊，Agent 需要进入内部系统，或者团队希望长期沉淀自己的 AI 能力，那么开放、可自托管的 Runtime 会变得更有意义。
销售真正珍贵的，从来不是把 CRM 填完整。
而是判断这个客户为什么买、什么时候该推进、下一步应该谈什么。
如果 Agent 能把查询、整理、记录和重复跟进接过去，让销售把时间重新花在客户身上，这件事就已经足够有价值。