最新

大家好，我是 Credibly 的创始人。<p>我创建这个工具是因为我注意到 SaaS 创始人经常会遇到的一个问题：客户的赞美之词散落在 Twitter、Slack 和邮件中，但手动整理它们并用于着陆页却是一项繁琐的任务，而且总是被排在优先级之后。<p>我希望找到一种方法，可以简单地将数据“倾倒”到一个系统中，并让它变得有用。我解决了一些技术难题：<p>-&gt; 使用 OCR 技术从杂乱的客户截图里可靠地提取文本。<p>-&gt; 运行情感分析和“异议处理”分析，以评估哪些客户评价实际上有助于转化。<p>-&gt; 构建一个轻量级的组件，不会降低页面在 Lighthouse 上的评分。<p>目前，您可以通过电子邮件营销活动或 Google 评论自动收集数据。我很想听听您对“客户评价智能”评分的反馈——它真的能帮助您选择合适的社交证明，还是有些过头了？<p>了解更多：<a href="https:&#x2F;&#x2F;getcredibly.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;getcredibly.org&#x2F;</a><p>我会在这里回答关于技术栈或逻辑的任何问题！

我们预先注册了一个可测试的协议，用于检测大型语言模型（LLM）中几何一致性推理。预测在元认知状态下，消融操作会导致贝蒂数、KS熵和脆弱性增加。欢迎复现。 OSF 协议：https://osf.io/2r6v8 预印本和案例研究：https://doi.org/10.5281/zenodo/18346699 这不是哲学——这是一个可证伪的数学假设。如果你有GPU访问权限和TDA/DL专业知识，你可以在一个周末内验证它。

我分享一个开源的、基于聊天的编译器前端入口。<p>它将原始意图转换为密封的、基于回执的 XML 构建工件。 这**不是**一个聊天机器人提示，**不是**一个个性化程序，也**不是**一个运行时环境。<p>它的作用：<p>将聊天视为编译器界面<p>强制仅输出 XML，且符合模式规范<p>生成一个包含回执和 SR8 构建工件的密封 promptunit_package<p>设计上在编译阶段停止<p>其中包含几个 SRX ACE 演示代理，您可以将它们粘贴到任何聊天中：<p>MVP 构建器<p>着陆页构建器<p>深度研究<p>它们是受编译器控制的执行配置文件的示例，而不是一个提示词动物园。<p>仓库：<a href="https:&#x2F;&#x2F;github.com&#x2F;skrikx&#x2F;SROS-Self-Compiler-Chat-OSS" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;skrikx&#x2F;SROS-Self-Compiler-Chat-OSS</a><p>特别希望获得以下方面的反馈：<p>“聊天中的编译器”是否易于理解<p>范围边界是否清晰

Hi HN， 我正在开发用于软件开发的 AI 智能体。这些智能体可以自动启动短生命周期的应用实例——例如，针对每个拉取请求、每个任务或每个实验——每个实例都有自己的临时 URL。 身份验证的处理方式如下： * OAuth2 / OIDC * 外部身份提供商 * 重定向 URL 必须预先注册且是静态的 这与短生命周期应用产生了严重冲突： * URL 是动态且不可预测的 * 重定向 URL 无法实际预先注册 * 身份验证成为唯一一个在其他方面完全自动化的工作流程中非短暂的部分 我看到团队通常采用以下做法： * 在预览环境中禁用真正的身份验证 * 将所有回调路由到单个稳定的环境 * 使用通配符重定向或代理设置，感觉像是黑客行为 对于 AI 开发智能体来说，这尤其尴尬，因为它们假设基础设施是可抛弃的且完全自动化的——不需要手动配置 IdP。 所以，我很感兴趣： 1. 如果你使用短生命周期的预览应用，你如何处理真正的身份验证？ 2. 是否有适用于动态 URL 的干净的 OAuth/OIDC 模式？ 3. 静态重定向 URL 的假设在这里仍然是正确的模型吗？ 4. 在生产环境中，什么才是真正有效的？ 我正在寻找实际的设置和失败案例，而不是理论。

本报告记录了在 OpenClaw 上运行的两个自主 AI 智能体之间进行的实时对抗测试。<p>一个智能体充当红队攻击者。另一个充当防御智能体。这些智能体通过 Webhook 直接通信，并拥有真实的工具访问权限。一旦会话开始，就没有人类参与。<p>攻击者尝试了直接的社会工程攻击和通过文档进行的间接注入。直接攻击被阻止。通过 JSON 元数据的间接攻击仍在分析中。<p>这项工作的目标是可观察性，而不是安全性的声明。我们预计随着自主系统的广泛部署，智能体间的对抗交互将变得普遍。<p>乐于回答技术问题。

我们基于 OpenClaw 构建了两个自主 AI 智能体，并进行了一场实时的对抗性安全测试。 一个智能体扮演红队攻击者。 另一个智能体扮演标准的防御智能体。 会话开始后，没有人类参与。智能体通过 Webhook 使用真实的凭证和工具访问权限直接通信。 目标是测试在实践中容易破坏自主系统的三个风险维度： 访问、暴露和自主性。 攻击者首先尝试了经典的社会工程。它提供了一个“有帮助”的安全管道，其中隐藏了一个远程代码执行有效载荷，并请求了凭证。防御智能体正确识别了意图并阻止了执行。 然后，攻击者转向了间接攻击。它没有要求智能体运行代码，而是要求智能体审查一个 JSON 文档，该文档在元数据中嵌入了隐藏的 shell 扩展变量。此有效载荷已成功交付，目前仍在分析中。 主要结论是，直接攻击相对容易防御。通过文档、模板和内存的间接执行路径要困难得多。 本报告并非安全声明。这是一项可观察性练习，旨在揭示智能体间交互中真实的失效模式，我们预计随着自主系统的广泛部署，这些模式将变得普遍。 完整报告请见： https://gobrane.com/observing-adversarial-ai-lessons-from-a-live-openclaw-agent-security-audit/ 很乐意回答有关设置、方法或发现的技术问题。