[Discuss] Can I use this architecture in Chrome extension?
Closed this issue ยท 3 comments
Hi, I'm a developer of Chrome Extension.
Chrome Extensions have restrictions on the eval function and cannot directly execute code. I'm looking for a solution that allows script inject to web pages, but needs to ensure the scripts are safe (no network requests, no cookie reading operations), while still being able to use certain libraries like jQuery. Would the current architecture support this kind of usage?
Additionally, I'm very curious about which scenarios this project is most hoping to address?
Interesting case!
Our SDK is built with AI agents execution in mind, so the whole execution model is optimized for that case, with statefulness, execution serialization, and for sure is not built for speed, so running complex programs in AgentScript would come with substantial overhead.
However you can still try to use it for your case. Please check out runtime tests for some more low level view of how to do that:
https://github.com/AgentScript-AI/agentscript/tree/main/packages/core/src/runtime/tests
Some of the functions are not exported from the core library, like parseScript, so you may need to fork the repo to make it work. In the future I'm planning to split it into multiple libraries, so you may find it easier then.
Also, some JS features are still not implemented, like destructurization, spread operator or loops, but they should be done anytime soon. Only a subset of native functions is supported, and cannot be extended right now (feel free to contribute to that if you want ๐). Custom functions are written as so called tools, and they have pretty complex requirements for your case (like input and output need to be known in runtime and serializable, no DOM elements for example), so it might be best to allow passing custom set of native functions from outside.
We are super early stage, so SDK development may go in pretty unpredictible directions, so stay tuned! ๐
Also the execution model is little simplified, to simplify code generation by LLM, for example, AgentScript code is always written as synchronous code (no awaits), and runtime automatically detects promises and awaits them.
I'm also considering other simplifications, like automatically null coalescing all member access statements...
Thanks for your detailed explanation.
I think there scenarios where your sdk would be useful.
For example, organizing the information on this page into a table.(https://www.cursor.com/changelog)
Method A would be to give the entire page to the model, this would encounter issues with too much content and structural chaos.
Method B give the page structure(xml, or pure html), and have the model generate a piece of JS code to extract the content, similar to executing code in the console
items = $.find("some class")
items = items.map
- return {'date': xx, 'content': xx, 'version': xx}