最新

我构建了一个仅在浏览器中运行的工作室，用于设计和编排MCP代理系统，以便进行开发和实验。整个技术栈——工具创建、多代理编排、RAG、代码执行——都通过WebAssembly从一个静态HTML文件中运行，无需后端。 这个项目的赌注是：WASM是一个严格的沙盒，完全免费。当你使用大型语言模型（LLM）生成工具（或手动编写工具）时，工作室会对源代码进行AST验证，懒惰地注册，并在首次调用时进行即时编译到Pyodide。SQL工具在DuckDB-WASM的Web Worker中运行。内置的RAG通过Transformers.js使用Xenova/all-MiniLM-L6-v2进行设备内嵌入。没有任何数据离开浏览器；关闭标签页，整个技术栈就消失了。WASM边界使得在本地安全执行LLM生成的代码成为可能——无需Docker，无需每个租户的容器，无需服务器。 在工具层之上，有一个包含10种编排策略的代理系统： - 监督者（路由器 → 1个专家） - 专家混合（并行 + 合成器） - 顺序管道 - 计划与执行（规划者分解，工作者执行） - 群体（同行交接） - 辩论（参赛者 + 裁判） - 反思（演员 + 评论者循环） - 层级（经理通过ask_<persona>工具委派） - 循环（小组 + 主持人） - Map-Reduce（分割器 → 并行 → 聚合器） 你可以通过可视化方式构建团队：将工具芯片拖放到服务图上的角色节点，选择一种策略，拓扑结构会自动调整以匹配。每个角色会自动注册为MCP工具（ask_<name>），以及一个agent_chat(query, strategy?)元工具。一个捆绑的Node桥接通过标准输入输出与Claude Desktop通信，并通过WebSocket与您的标签页连接——您的浏览器变成了一个MCP服务器。 完成后，导出功能会为您提供一个真实的Python MCP服务器：server.py、agentic.py、tools/*.py、Dockerfile、requirements.txt、.env.example。导出的agentic.py是与在浏览器中运行的相同编排逻辑的忠实Python移植，因此可部署的工件与原型行为完全一致。 同时还提供了项目包。将整个项目导出为一个单独的.agentpack.json。通过扫描工具源代码中的os.environ.get(...)并与网络白名单交叉引用，自动检测所需的外部服务（OpenAI、GitHub、Stripe、Anthropic、Slack、Notion、Linear等）。接收者会获得一个导入向导，提示输入凭证。清单是可审查的、可共享的，并且从不携带秘密。 有些事情我诚实地不太确定： - 10种策略可能太多了。我猜大多数用户只需要监督者、专家混合和辩论。欢迎提供哪些策略实际上有效的数据。 - 浏览器冷启动（Pyodide首次加载时的预热）尽管进行了积极的缓存，仍然对用户体验造成了真实的影响。 - bridge.js是唯一的非浏览器部分。托管变体显然是下一步的方向。 该项目使用Pyodide、DuckDB-WASM、Transformers.js、OpenAI聊天补全（或通过Transformers在浏览器中运行的本地Qwen 1.5 0.5B以实现完全离线模式）构建。约5K行的HTML/CSS/JS在一个文件中。 我真心好奇，在浏览器标签页中运行这么多LLM生成的代码对你来说是否合理，或者是否让你感到悚然。

大家好，我正在开发一个命令行工具，可以轻松运行Claude、Codex、Gemini、Pi和OpenCode中的任何模型。<p>它还可以作为API密钥管理器，支持多个提供商或OpenAI/Claude/Gemini账户。您可以添加OpenRouter、Poe、Vercel AI网关等。<p>该工具内置了一个免费的提供商，使用Deepseek-V4，无需登录或API密钥，准备好后可以添加您自己的密钥。<p>安装后，您可以立即尝试Claude（无需配置，无需登录）：<p>aivo claude<p>希望对某些人有所帮助。

在二月份，我向谷歌的漏洞奖励团队报告了以下内容： 1) 用户访问 https://attacker.tld（这可以是故意的，也可以是通过弹出窗口访问的）。 2) attacker.tld 通过状态码 302/301 将用户重定向到 OAuth 端点。 2.1) 重定向 1: https://accounts.google.com/o/oauth2/v2/auth? client_id=[client-id] &response_type=code &scope=openid email &redirect_uri=https://iap.googleapis.com/v1/oauth/clientIds/[client-id]:handleRedirect &code_challenge=[已编辑] &code_challenge_method=S256 &cred_ref=true &state=[已编辑] 2.2) 重定向 2: https://iap.googleapis.com/v1/oauth/clientIds/[client-id]:handleRedirect? state=[已编辑] &code=[已编辑] &scope=email openid https://www.googleapis.com/auth/userinfo.email &authuser=0 &prompt=none 2.3) 重定向 3: https://attacker.tld/?gcp-iap-mode=AUTHENTICATING &redirect_token_v2=[已编辑] 3) 用户的电子邮件地址在 2.3 的结果中直接在 HTTP 401 响应中以 attacker.tld 域名的形式提供。因此，我们知道用户的电子邮件地址在未获得同意的情况下被共享。 由于没有收到回复，我以为该问题仍在处理中。几周后，我再次回到他们的门户网站进行确认。他们已经回复，但仅在他们的门户内。工单来回沟通，声称无法重现该问题。最后，我向他们提供了 https://withpersona-gov.com 的实时 URL。 他们再次辩称该漏洞无法重现。巧合的是，在我提供 URL 后仅两天，该网站就更改为重定向到主要的 withpersona 域名。 显然，这将是或仍然是对隐私法的重大侵犯。我感到自己在这里被误导了。