Feat/sandbox provisioner shared storage#581
Feat/sandbox provisioner shared storage#581xerrors merged 17 commits intoxerrors:feat/agent-sandboxfrom
Conversation
使用 psycopg_pool 作为 LangGraph checkpointer 连接池，并在启动时执行 setup() 确保表存在；Windows 下切换为 SelectorEventLoopPolicy 以兼容 psycopg 异步模式。
…ovisioner-shared-storage' into feature/sandbox # Conflicts: # server/routers/chat_router.py # src/config/app.py # src/services/chat_stream_service.py # uv.lock # web/src/components/AgentChatComponent.vue # web/src/components/AgentPanel.vue
…' into feat/sandbox-provisioner-shared-storage # Conflicts: # pyproject.toml # src/agents/common/base.py
# Conflicts: # pyproject.toml # uv.lock # web/src/components/AgentChatComponent.vue
|
@xerrors 我看有新分支有沙箱了，大概看了下是基于deerf-flow那一套实现的；当前提交的，去除了本地容器那一套，全部采用agent-sandbox SDK来对接，依赖相应的沙箱容器镜像，但是相应的，容器镜像有更多的功能，比如浏览器，skills，mcp等；生态更强，后续可以继续支持；可以看看是否采纳呢 |
|
app.py中，处理k8s pod启动，pvc挂载是踩过坑的，可以一起讨论 |
|
基于deer-flow的sandbox实现，之前搞了一版，被我关了 https://github.com/xerrors/Yuxi-Know/pull/558；原因就是要维护太多套api了，维护成本太高。和 https://github.com/1165506270/Yuxi-Know.git 的对比，不够精简，架构不够清晰。 |
|
我上次看到了，我对后端的很多地方不够了解，然后想着就自己去照着 deer-flow 弄了一套。重点还是得和现有的文件系统能兼容，比如 skills / 附件（因为文件少，当前是启动的时候从 MINIO 复制到 sandbox），然后前端的 agentpanel 要能浏览文件。 我实现的那一版现在马马虎虎是能实现这一套，测试起来没什么问题，最近一周的琢磨也终于是理顺了。我最近试一下你的版本。 不过最难搞的地方在于，后端架构改动了一下，现在 merge 能 merge 到 main 分支，但是和 v0.6.x 的 merge 难度要很大了。 |
|
简单看了一下，确实简洁了不少，如果说基础功能在实现起来都没什么问题的话，还是用大佬的方案吧，这方面我还是在学，刚学会一个方案，又来一个进阶方案哈哈哈哈哈。 不过需要得花时间考虑怎么合并了 |
| { text: '其他配置', link: '/latest/advanced/misc' }, | ||
| { text: '生产部署', link: '/latest/advanced/deployment' } | ||
| { text: '生产部署', link: '/latest/advanced/deployment' }, | ||
| { text: 'Kubernetes 部署', link: '/latest/advanced/kubernetes-deployment' } |
|
我先把这次提交合并到 main 的一个复制分支，然后我再处理冲突吧 |
4 participants
变更描述
基于 @1165506270 https://github.com/1165506270/Yuxi-Know.git 实现的sandbox，在公司内，k8s环境中上线了，各工具接口也全部测试了，还解决了接口权限和目录权限不一致的问题
变更类型
测试
相关日志或者截图
说明
（可选）有什么需要特别说明的吗？
💡 提示: 提交前可以运行
make lint和make format检查代码规范