最新

构建了两个东西： 预测器 Agent - 抓取 Polymarket 上表现最佳的交易员数据，找出他们的共识押注，并对入场质量进行评分。目前追踪 51 个真实信号。 AgentWallet - 我构建的“财务约束”，防止 Agent 失控。包含支出限额、审批门槛、时间窗口以及完整的审计追踪。 实时演示： 预测器信号：<a href="https:&#x2F;&#x2F;predictor-dashboard.vercel.app" rel="nofollow">https:&#x2F;&#x2F;predictor-dashboard.vercel.app</a> AgentWallet：<a href="https:&#x2F;&#x2F;agentwallet-dashboard.vercel.app" rel="nofollow">https:&#x2F;&#x2F;agentwallet-dashboard.vercel.app</a> 构想：AI Agent 将需要花费资金。需要有人来构建安全措施。这就是 AgentWallet。 GitHub：<a href="https:&#x2F;&#x2F;github.com&#x2F;JackD720&#x2F;agentwallet" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;JackD720&#x2F;agentwallet</a>

我正在寻找能找到需要招聘兼职人才以启动业务的初创企业创始人的最佳平台。我在 SaaS 领域拥有 15 年的产品构建经验，希望能与其他创始人建立联系。

我们曾被告知，人工智能将开启一个时代，小团队能在几周内构建出企业级产品。它们在哪里？Excel 的竞争者在哪里？Outlook 的竞争者在哪里？Jira 的竞争者在哪里？ 这一切从未发生。这完全是个神话。大型科技公司依然占据主导地位，仅此一点就证明了我们当前模型的无力和徒劳。

我审计了一个 AI 编码助手——发现了 50 个攻击向量 https://dev.to/dmitry_labintcev_9e611e04/riding-the-hype-security-audit-of-ai-agent-clawdbot-2ffl

自动化亚马逊购物或类似复杂网站的常见方法是使用大型云模型（通常具有视觉能力）。我想测试一个矛盾：一个约 30 亿参数的本地 LLM 模型能否仅使用结构化页面数据（DOM）加上确定性断言来完成流程？ 这篇文章总结了同一任务（搜索 → 第一个产品 → 加入购物车 → 在亚马逊结账）的四次运行。关键的比较是 Demo 0（云基线）与 Demo 3（本地自主）；Demo 1–2 是中间控制。 更多技术细节（架构、代码摘录、额外日志片段）： [https://www.sentienceapi.com/blog/verification-layer-amazon-case-study](https://www.sentienceapi.com/blog/verification-layer-amazon-case-study) Demo 0 vs Demo 3： Demo 0（云端，GLM‑4.6 + 结构化快照） 成功：1/1 次运行 tokens：19,956（比约 35k 的估计减少约 43%） 时间：约 60,000 毫秒 成本：云 API（变化） 视觉：不需要 Demo 3（本地，DeepSeek R1 规划器 + Qwen ~3B 执行器） 成功：7/7 步（重新运行） tokens：11,114 时间：405,740 毫秒 成本：增量 0.00 美元（本地推理） 视觉：不需要 延迟说明：本地堆栈在这里端到端较慢，这主要是因为推理在本地硬件上运行（配备 M4 的 Mac Studio）；云基线受益于托管推理，但有每个 token 的 API 成本。 架构 之所以有效，是因为我们改变了控制平面并添加了一个验证循环。 1) 限制模型看到的内容（DOM 裁剪）。 我们不提供整个 DOM 或截图。我们收集原始元素，然后运行一个 WASM 过程来生成一个紧凑的“语义快照”（角色/文本/几何）并裁剪其余部分（通常约为 95% 的节点）。 2) 将推理与行动分开（规划器 vs 执行器）。 规划器（推理）：DeepSeek R1（本地）生成步骤意图 + 之后必须为真的内容。 执行器（行动）：Qwen ~3B（本地）选择具体的 DOM 操作，如 CLICK(id) / TYPE(text)。 3) 使用 Jest 风格的验证来控制每一步。 在每个操作之后，我们断言状态变化（URL 更改、元素存在/不存在、模态/抽屉出现）。如果所需的断言失败，则该步骤失败，并附带工件和有界重试。 最小形状： ok = await runtime.check( exists(&quot;role=textbox&quot;), label=&quot;search_box_visible&quot;, required=True, ).eventually(timeout_s=10.0, poll_s=0.25, max_snapshot_attempts=3) “看起来很聪明的代理”和“有效的代理”之间发生了什么变化 日志中的两个例子： 确定性覆盖以强制执行“第一个结果”意图：“执行器决策… [覆盖] first_product_link -> CLICK(1022)” 处理抽屉，验证并强制执行正确的分支：“结果：通过 | add_to_cart_verified_after_drawer” 重要的是，这些不是事后分析。它们是内联门：系统要么证明它取得了进展，要么停止并恢复。 总结 如果你想让浏览器代理可靠，最有影响力的举措不是更大的模型。而是限制状态空间，并通过每一步的断言明确成功/失败。 代理的可靠性来自验证（对结构化快照的断言），而不仅仅是扩大模型规模。