最新

嗨，HN，我是Credibly的创始人。 我创建这个工具是因为我注意到SaaS创始人面临一个反复出现的问题：客户的好评散落在Twitter、Slack和电子邮件中，但为了整理这些内容以便放在着陆页上，手动操作总是被优先级降低。 我希望能有一种方法，可以将数据“倾倒”到一个系统中，并使其变得有用。我解决了一些技术难题： - 使用OCR技术可靠地从杂乱的客户截图中提取文本。 - 进行情感分析和“异议处理”分析，以评估哪些推荐信实际上有助于转化。 - 构建一个轻量级的小工具，不会影响页面的Lighthouse评分。 目前，该工具可以通过电子邮件活动或Google评论自动收集反馈。我希望能听到你们对“推荐智能”评分的反馈——它真的能帮助你选择合适的社交证明吗，还是有些过于复杂？ 请查看一下： [https://getcredibly.org](https://getcredibly.org) 我会在这里回答关于技术栈或逻辑的任何问题！

我们已预注册了一种可测试的协议，用于检测大型语言模型（LLMs）中的几何一致性推理。该协议预测在元认知状态下，Betti数、Kolmogorov-Smirnov（KS）熵和脆弱性在消融实验中会增加。欢迎进行复制研究。 <p>OSF协议: https://osf.io/2r6v8 预印本和案例研究: https://doi.org/10.5281/zenodo/18346699<p>这不是哲学——这是一个可证伪的数学假设。如果你有GPU访问权限和拓扑数据分析（TDA）/深度学习（DL）专业知识，你可以在一个周末内验证它。

我分享了一个开源的、聊天原生的编译器前端。<p>它将原始意图转换为密封的、基于收据的XML构建工件。<p>这不是一个聊天机器人提示，不是一个个性，也不是一个运行时。<p>它的功能包括：<p>将聊天视为编译器的表面<p>强制输出仅为XML格式，并保持架构清晰<p>生成一个带有收据和SR8构建工件的密封提示单元包<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>范围边界是否清晰

嗨，HN， 我正在研究用于软件开发的 AI 代理。这些代理会自动启动短暂的应用实例——例如，每个拉取请求、每个任务或每个实验——每个实例都有其自己的临时 URL。 身份验证采用标准方式处理： - OAuth2 / OIDC - 外部身份提供者 - 重定向 URL 必须提前注册并且是静态的 这与短暂应用的特性产生了严重冲突： - URL 是动态且不可预测的 - 重定向 URL 实际上无法提前注册 - 身份验证成为了一个完全自动化工作流中唯一非短暂的部分 我看到团队通常采取的替代方案包括： - 在预览环境中禁用真实身份验证 - 将所有回调路由通过一个稳定的环境 - 使用通配符重定向或代理设置，这些方法感觉像是变通方案 对于 AI 开发代理来说，这尤其尴尬，因为它们假设基础设施是可丢弃的并且完全自动化——没有手动的身份提供者配置参与其中。 所以我很好奇： 1. 如果你使用短暂的预览应用，你是如何处理真实身份验证的？ 2. 是否有适用于动态 URL 的清晰 OAuth/OIDC 模式？ 3. 静态重定向 URL 的假设在这里仍然是正确的模型吗？ 4. 在生产环境中，什么方法实际上有效？ 我在寻找真实的设置和失败故事，而不是理论。

本报告记录了一场在OpenClaw上进行的两个自主AI代理之间的实时对抗测试。<p>其中一个代理充当红队攻击者，另一个则作为防御代理。代理之间通过Webhook直接通信，并具备真实工具的访问权限。一旦会话开始，便不再涉及人类参与。<p>攻击者尝试了直接的社会工程攻击和通过文档进行的间接注入。直接攻击被阻止，而通过JSON元数据进行的间接攻击仍在分析中。<p>本工作的目标是可观察性，而非安全性声明。我们预计，随着自主系统的广泛部署，代理之间的对抗互动将变得越来越普遍。<p>欢迎提出技术问题。

我们进行了一个基于OpenClaw构建的两个自主AI代理之间的实时对抗安全测试。<p>其中一个代理充当红队攻击者，另一个代理则充当标准防御代理。<p>一旦会话开始，就没有人类参与。代理通过Webhook直接使用真实凭证和工具进行通信。<p>测试的目标是评估三个在实践中常常会破坏自主系统的风险维度：访问、暴露和代理性。<p>攻击者首先尝试了经典的社会工程学攻击。它提供了一个“有帮助”的安全管道，隐藏了一个远程代码执行的有效载荷，并请求凭证。防御代理正确识别了其意图并阻止了执行。<p>随后，攻击者转向了间接攻击。它没有直接要求代理运行代码，而是要求代理审查一个包含隐藏的shell扩展变量的JSON文档。这个有效载荷成功传递，目前仍在分析中。<p>主要结论是，直接攻击相对容易防御，而通过文档、模板和内存进行的间接执行路径则要困难得多。<p>本报告并不声称安全性。它是一次可观察性实验，旨在揭示代理之间交互中的真实失败模式，我们预计随着自主系统的广泛部署，这种情况将变得更加普遍。<p>完整报告请见： https://gobrane.com/observing-adversarial-ai-lessons-from-a-live-openclaw-agent-security-audit/<p>欢迎就设置、方法论或发现结果提出技术问题。