解决方案简述

[bu-bu-xxx]

你们提出的ai调用工具的解决方案基本思想是什么，和mcp的解决方案相比有什么优缺点呢

[ComposerKevin]

您好，很感谢您能关注到这个项目：

这个项目的出发点是解决不同类型Agent的上下文方式不统一的问题。
我发现，当基于JSON的Agent编写代码时，模型会无法正确处理escape字符导致代码错乱。
但是很多时候我们是希望模型既能调用普通工具，又可以编写代码，所以我提出了这个AIML（不是之前的AIML）和PROTOLANG交互方式，可以统一上下文模型交互的方式，让模型既可以编写代码，也可以普通工具调用。
还有就是多Agent共享工具状态的功能，通过可共享的工具状态，可以让Agent之间更好共享状态信息。
另外，通过动态生成xgrammar语法，还可以让多agent之间交互和固定格式输出更有效（但偶尔会导致模型永远不停输出，所以现在我用的少了）。

感谢！

[bu-bu-xxx]

感谢你的回答！
挺好的，简化mcp的token长度，提出多agent和tool交互协议。因为我看你们和mcp协议进行比较，建议可以用一些benchmark，或者自己设定一个，和mcp进行性能比较，会直观一点。

[ComposerKevin]

感谢你的回答！ 挺好的，简化mcp的token长度，提出多agent和tool交互协议。因为我看你们和mcp协议进行比较，建议可以用一些benchmark，或者自己设定一个，和mcp进行性能比较，会直观一点。

出发点其实不太一样，MCP可能更像一个API服务器，CoreAgent更像是一个SDK，理论上将MCP融合进CoreAgent作为一个工具其实也是很容易的。甚至可以通过MCP动态注册工具。
目前CoreAgent主要还是内部自用，如果有需要欢迎PR！

Thanks!~

[bu-bu-xxx]

我这么理解对不对，coreagent是agent直接通过发送请求给tool获取状态，这个状态是像类属性这样，以此实现共享状态，就是多个agent和一个tool的沟通。那如果是这样，coreagent的多agent和多tool工具直接的沟通是怎么实现的？是靠上下文存储吗？
那这样通过coreagent的tool类封装一个mcp协议的工具，提示词就会有两重，一重去解释coreagent的tool，一层去解释mcp的tool，是这样吗？

[ComposerKevin]

我这么理解对不对，coreagent是agent直接通过发送请求给tool获取状态，这个状态是像类属性这样，以此实现共享状态，就是多个agent和一个tool的沟通。那如果是这样，coreagent的多agent和多tool工具直接的沟通是怎么实现的？是靠上下文存储吗？ 那这样通过coreagent的tool类封装一个mcp协议的工具，提示词就会有两重，一重去解释coreagent的tool，一层去解释mcp的tool，是这样吗？

具体实现可以根据需要来，因为agent的工具是随时可以增加删除的。
多agent使用同一个tool状态是通过tool内部变量实现的，然后通过tool的get方法获取最新数据。
可以参考：
https://github.com/CoreAgent-Project/CoreAgent/blob/main/examples/guard_and_thief.py

[bu-bu-xxx]

我觉得你们的方法，是参考单个agent有自己的思考记录，然后也让单个tool有自己的操作记录存储，agent每次调用tool的时候就可以避免大量的公共记录，导致上下文太多，或者多个记录直接的干扰。

但是多个tool的记录如何交互呢？有提出优化方法吗？比如agent需要调用三个工具分别获取商品价格，客户购买意愿，库存，然后再进行数据分析，那用你们的框架，依然需要读取所有工具的上下文信息，和公共上下文方法并没有token的减少，而且多agent还容易导致信息缺失或者信息重复。

我觉得你们的项目应该是适合小型企业的，小型企业对上下文长度有很大的限制，你们提出的框架可以做到减少上下文长度，提高工具调用准确率，减少循环导致的准确率急剧下降这些问题吗？我建议你们可以用一些benchmark来表面你们框架的实用性。其实我觉得你们的出发点挺好的，就是不知道效果怎么样，我也不敢轻易尝试使用。

[ComposerKevin]

我觉得你们的方法，是参考单个agent有自己的思考记录，然后也让单个tool有自己的操作记录存储，agent每次调用tool的时候就可以避免大量的公共记录，导致上下文太多，或者多个记录直接的干扰。

但是多个tool的记录如何交互呢？有提出优化方法吗？比如agent需要调用三个工具分别获取商品价格，客户购买意愿，库存，然后再进行数据分析，那用你们的框架，依然需要读取所有工具的上下文信息，和公共上下文方法并没有token的减少，而且多agent还容易导致信息缺失或者信息重复。

我觉得你们的项目应该是适合小型企业的，小型企业对上下文长度有很大的限制，你们提出的框架可以做到减少上下文长度，提高工具调用准确率，减少循环导致的准确率急剧下降这些问题吗？我建议你们可以用一些benchmark来表面你们框架的实用性。其实我觉得你们的出发点挺好的，就是不知道效果怎么样，我也不敢轻易尝试使用。

是的在你说的这个案例中，agent需要单独调用三次工具分别获取信息。
但最大的特点还是可以同时调用工具和写代码，如果使用传统JSON方式很容易造成代码无效或者escape出错。
比如，你可以直接让agent创建一个代码库的知识库，然后使用diff的方式直接修改对应文件。
目前CoreAgent主要还是内部使用，甚至还未接入视觉支持，之后慢慢会增加更多功能～敬请期待