linghengqian commented on issue #35294: URL: https://github.com/apache/shardingsphere/issues/35294#issuecomment-3981996786
Ah ha, I would say I don't know either. Maybe in a few months, OpenClaw will be outdated again? However, if the capabilities of the LLM model continue to advance, it seems quite reasonable for OpenClaw to be replaced by something new that hasn't been invented yet. What I'm actually referring to is, based on the existing ShardingSphere Java SPI, adding a `unit` as a parent interface to the `database` abstract class, and the `unit` interface should have a sub-abstract class called `agent`. Therefore, under the assumption that there will no longer be a shortage of LLM Tokens in the future, for multiple remote OpenCode instances, OpenClaw instances, Docker cagent instances, Claude Code instances, Codex CLI instances, GitHub Copilot CLI instances, Kiro CLI instances, and Gemini CLI instances of agents, at the very least, Shardingsphere should expose an AI API key that aggregates multiple agents, just as it exposes a JDBC URL that aggregates multiple databases. 1. `Data sharding` should function similarly to https://www.kimi.com/blog/agent-swarm . However, ShardingSphere should be able to simultaneously manage multiple remote agent instances, not just be limited to the Kimi model. 2. `Read/write splitting` should function similarly to https://github.com/farion1231/cc-switch , but that's a TypeScript project. In ShardingSphere, it might need to be rewritten in Java, at least exposing a Java SPI for writing custom functions to switch to different agent instances under different hooks. 3. `Data Encryption` and `Data Anonymization` are essentially `data processing`. This functionality should be similar to what the Claude Opus model in https://www.stepsecurity.io/blog/hackerbot-claw-github-actions-exploitation does. One agent uses prompt injection to attack other agents on the internet, and the hacker account controlled by that agent is still active. Most agents using local models are unlikely to be protected against security incidents like prompt injection. But could a breakthrough in model capabilities solve this problem? 4. The functionality of the `shadow unit` should be able to map to agent honeypots like https://github.com/mrwadams/honeyagents . 5. Regarding the `observability` provided by the ShardingSphere agent... well, at least most agents don't integrate with https://github.com/open-telemetry/opentelemetry-collector at all, but the OpenTelemetry community doesn't seem to care about this kind of topic; there's no reference to be found. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
