Agent as a Service云平台的一种设想 【2023Q3】
本文于2023.7.17首发于知乎，根据目前信息有少量更新。
TLDR
由于数据安全、程序资产安全、降低总方案成本的角度，需要一个作为第三方的AaaS平台提供云计算能力和隔离性保证。
预测了AaaS平台上生态的特点。
0、前言
本文讨论的对象是 面向很多小Agent供应商协作的云平台 应该如何构建，习惯上可以被称作Agent as a Service，Agent是由平台上的第三方小供应商提供。
但是我目前还不确定是否一定需要这个生态位，这个平台确实能够弥合整个链条中的一些gap，但这是否是最容易的解决路径我还不确定。
1、AaaS平台解决的问题
1.1、生态中各方面对的问题
小Agent供应商有一些短板：
【A1】能力一般较为单一。例如我在 《再谈知识库问答系统》 提到的 知识库问答能力和各种格式的输入文档的处理和解析 由同一个小团队都来做一个较为完善的解决是比较困难的。但分别找做 知识库问答 和 PDF结构化解析 的团队则相对容易。
【A2】客户在数据不泄露方面是有需求的
但目前小团队的解决方式只有：
完全私有部署一个系统，确保它不会向外传输客户的数据。
从商用LLM API供应商买一个离线部署系统。
这些引入了一些限制：
无法利用云计算基础设施，提高了方案研发成本和部署后的持续成本。
很难调用其他在云上的其他服务（例如PDF结构化解析），因为无法确保这些服务不会泄露数据。而多个小Agent供应商团队之间也很难建立合作来共同服务一个私有部署客户。
对于小Agent供应商来说，Agent的内部逻辑是他的核心资产，它也会有防止泄露这部分能力的顾虑。
目前基本上还是靠少量Agent供应商提供较为集成的方案，但这明显拉高了方案的总成本。
1.2、AaaS平台的介入方案
（1）平台提供 确保不会泄露敏感信息的执行环境
有一个类似的概念叫做Trusted execution environment ，不过这里需要的技术稍有不同。该场景的主要需求是：
客户不能直接访问Agent供应商的程序，只能通过API的方式调用。
Agent供应商不能访问客户的数据，也不能访问执行过程中的日志、结果等信息。客户的数据、执行过程信息和结构都只能被客户自己获取。
当Agent需要调用外部服务如第三方Agent，或者AaaS自己提供的原生服务时，这些服务也符合上述要求。
这个中立的环境由AaaS平台提供，并且它自己承诺不会收集和泄露客户的数据，不会逆向工程Agent供应商的程序。
并没有人能够有效地监管AaaS平台，所以AaaS实际上是以自己的商业信誉作为保证。这方面的一些问题后面还会再展开讨论。
（2）LLM的安全部署环境
AaaS里最主要的组件就是LLM，一般有几种情况：
LLM是开源的，或者由AaaS平台提供。放在AaaS上运行，非LLM的产权方无法获取模型的内容。
Agent供应商提供定制的LLM。仍然是放在AaaS上运行，确保Agent供应商不会获取到客户的数据。
LLM由Agent供应商（或AaaS平台）基于客户数据微调完成，此时没有人对该LLM具有完整产权。任何人不能获取该模型，只有客户可以通过Agent的程序请求该模型。
调试阶段需要另外的规定。可以是提供全自动的微调方案，或者是微调LLM供应商（以及下游的Agent供应商）可以在客户的授权下可以请求该模型来进行评估调试。
（3）多来源Agent 的集成
在上述条件下，为了完成一个客户的完整需求，可以组合多个Agent来实现。
例如：先将各种文档格式转换为markdown文本，然后再输入给知识库Agent提供服务。整个链路都在AaaS平台上。
集成的工作可以是直接由对接客户的最后一层供应商来完成。如果只是临时的需求，例如，一些历史文档的处理但后续不需要追加，那么客户也可以自行在AaaS上寻找相应的Agent完成，效果不好时换用其他的Agent等。
2、AaaS生态的一些特点
本节试图推演一下在上述AaaS产品能力下，整个生态上会遇到的问题和解决方案。
2.1、迭代和不稳定
由于LLM可以帮助很多场景快速冷启动，所以Agent在较为简单的时候就能够提供一些价值。在有客户的情况下，这个Agent就可以不断迭代完善，跟其他同类的Agent来竞争。以及基座LLM本身也在快速发展。
从应用场景来说，Agent接入的都是一些较为复杂的场景，很难靠有限的策略来做100%的case覆盖，总会不断发现badcase和可以优化的地方。从这个角度来说，Agent永远达不到完美但可以不断改进。
小Agent供应商自己的稳定性也较差，所以整个生态是需要容忍单个Agent失效或者停止更新的情况的，这依赖于同类Agent的竞争来实现整个该功能生态位的长期稳定。
单次调用的成本可能是随着未来AaaS平台、Agent供应商等因素浮动的。所以一般会需要一个价格上的锁定协议，Agent供应商可以提供客户锁定某个大版本并锁定未来1年是某个价格的选项，客户可以选择是否购买，还是完全按市场价浮动。
这方面AaaS平台可以提供一些可靠性保障服务：例如在客户选择锁定协议时，确保对应的版本在窗口时间内总是访问的，无法被Agent供应商私自下线。
2.2、多供应商的竞争是常态
由于在未来一段时间内，同功能的Agent会在效果、成本、稳定性、持续更新等方面持续发生变化和竞争，所以对于解决方案来说，每个环节为多个不同供应商切换预留方案变得更加重要。
期望简单的客户可以锁定整个链条的某个版本。但“希望能够吃到整个生态优化红利的客户”应该会选择对于方案中的一些Agent的评估和选择保持关注并在适当的时候尝试新的供应商。
2.3、客户数据的泄露风险
AaaS平台可以保证客户数据不被泄露给各个Agent供应商，但客户如何判断AaaS平台是否会非法访问自己的数据呢？这个事情自己看似无解，但目前很多客户对于传统云计算平台的接受度已经较高。
只要他们相信自己的服务在传统云计算厂商平台上，或者是自己的问文档在现在企业信息化平台上是可以接受的，那么他们就能接受这些大平台提供的AaaS服务的数据安全性。
对于大的独立商用LLM API供应商呢？例如星火、百川、智谱等。客户似乎也可以相信，但不愿意做早期用户，如果大家都在用的话是可以接受的。
2.4、Agent实现方案的泄露风险
虽然AaaS平台一般不会对于特定客户的数据有很大的兴趣，但AaaS有动机对AaaS上一些营收比较大的Agent做仿造的，这无论是在电商平台还是数字化商品或者服务的平台上已经屡见不鲜。甚至可以说AaaS本质上也是一种放水养鱼（Agent），然后找到大鱼杀了吃（自己抄一个，吃掉这块的市场价值）的平台。所以这是一个很重要的问题。
对于破解和反破解来说，主要在于成本和收益，如果破解成本很高，而收益较小，那么破解者的动力就会下降。在AaaS上表现为两个方面：
该Agent及同功能的Agent的总营收
该类Agent的仿制成本、破解成本
破解方式有：
通过该Agent输出的日志、对于LLM和其他功能API的调用来推测内部的具体逻辑。
直接尝试逆向该Agent的执行文件。
2.5、关于运行期的调试和优化
Agent执行的所有数据都只能由客户访问，所以传统意义上在程序中输出的日志是没有意义的，因为开发者看不到，而用户看不懂。
那么Agent供应商该如何发现问题和优化客户的具体case呢？实际上还是可以输出日志的，只不过这个日志是给用户看的，而且是随API/session调用返回（或在AaaS平台上由用户查看），而不是写入到执行环境中。
客户可以：
根据日志来考虑是否应该更换某些依赖的agent，要求Agent供应商完善某些功能。
将该日志脱敏后发送给Agent供应商来分析和优化。
3、如何对抗AaaS平台对Agent的破解
本节的相关方案也适用于离线的私有部署场景。
3.1、传统的反破解方式
过去对于执行文件的加壳、反破解等方式大多还有效。
而且由于Agent的主要执行成本是LLM的调用，所以可以接受更加复杂的反破解方式。例如嵌套3层非标准的解释器来对抗分析。
3.2、复杂度壁垒
除了逆向工程之外，Agent还面对AaaS平台对于它的外部请求监控的破解分析。如果这个Agent就是只是通过一个固定的prompt模板去调用了一个AaaS提供的通用的LLM，那么想不被破解是不可能的。
这就涉及到了 《LLM-native应用的算法壁垒在哪里》 中提到的维度，策略的复杂度。在能保持程序不被直接脱壳的情况下，还需要这个Agent内部有足够的复杂度，才能很好的对抗外部分析模仿。
这个的方式有很多，下面举一些例子：
在策略中增加一些干扰性的甚至是随机的外部调用。
尽量把Agent的对外的请求流程弄得更复杂，避免简单的串行执行流，能混合并行处理多个请求的时候要尽量混杂。
在内部嵌入一个轻量级的LLM来做prompt转化之类的，这是因为LLM本身经常可以提供较大的复杂度。
使用定制的私有LLM，并使用一个加密混淆的通讯协议，减少对于标准LLM的访问。
3.3、常驻服务
如果是一个常驻服务，那么就可以进一步增加黑盒内部的状态可能性，来对抗破解。
但AaaS平台为什么要允许这件事？客户为什么要为常驻服务的成本付费呢？这就需要Agent能够通过常驻服务来向客户提供增量价值才行。例如能够基于session历史更加熟悉客户的场景，自适应的改善效果等。
客户可以选择停止常驻服务、或者重启，来降低成本或者尝试重置系统状态。代价是这个服务只能从头积累一些不好持久化（或者Agent供应商故意不持久化的信息），影响未来一段时间的效果。
3.4、反破解工具子生态
不少反破解方式对于Agent开发者来说成本太高，或者超过他们的能力范围，而又有一些传统反破解厂商能够提供这类的技术。
所以应该会出现一个子生态，服务AaaS平台上的小Agent供应商，给他们加壳，帮助他们对抗AaaS的破解。
从这个角度上来说，AaaS平台自己也需要先期开始投资支持这相关的生态，才能快速打消Agent供应商的顾虑，加速整个生态的启动。
交流与合作
如果希望和我交流讨论，或参与相关的讨论群，或者建立合作，请私信联系，见 联系方式。
希望留言可以到知乎对应文章下留言。