一周热榜

我们的团队常常使用Slack，但我们无法访问Slack MCP，也找不到适合我们的解决方案，因此我们自己编写了一个agent-slack CLI工具。 - 可以粘贴Slack URL - 令牌高效 - 零配置（如果使用Slack桌面版会自动认证） 该工具会自动下载文件/代码片段。 同时也可以将Slack画布读取为Markdown格式！ MIT许可证

嘿，HN， 我是一名转行的量化物理学家。我和一些朋友“构建”了SymDerive，因为我们希望有一个符号数学库，设计上是“代理原生”的，同时又是一个对人类实用的工具。 这归结为两个主要目标： 1. 代理可靠性：我发现，当AI代理遵循无状态的函数式管道（类似Lisp风格）时，它们编写的代码要可靠得多。这可以防止它们产生状态变化的幻觉或在长的过程脚本中迷失。我希望有一个库默认强制执行“输入 -> 转换 -> 输出”的流程。 2. 缓解向Python的过渡：对于许多物理学家来说，Mathematica是他们的母语。我想提供一种方式来缓解这一过渡——提供一座桥梁，保持熟悉的语法（驼峰命名法、Sin、Integrate），同时在底层严格使用Python科学栈。 我构建的内容：这是一个围绕标准栈（SymPy、PySR、CVXPY）的函数式封装，作为一个独立的引擎，适用于任何人——无论是人类还是代理——喜欢基于管道的工作流程。 ```python # “管道”方法（对代理更清晰，对人类可读） result = ( Pipe((x + 1)**3) .then(Expand) .then(Simplify) .value ) ``` “氛围”特性： - Wolfram语法：Integrate、Det、Solve。如果你懂数学，你就懂这个API。 - 模块化：重的功能（符号回归、凸优化）是可选安装（[regression]、[optimize]）。除非你要求，否则不会膨胀你的虚拟环境。 - 物理工具：我添加了我实际使用的工具——广义相对论的抽象指标符号、因果模型的克拉默斯-克罗尼希等。 这绝对是有主见的，但如果你正在构建代理来进行严格的数学计算，或者只是想要一个熟悉的函数式接口来进行自己的研究，这可能会有所帮助。 我发现协调者（Claude Code等）在学习工具和将任务发送到正确角色方面相当不错，我们对它的效果感到惊讶。 代码库在这里：https://github.com/closedform/deriver 如果被嘲笑得太狠我会哭的。

嗨，HN， 我和我的朋友一直在尝试使用大型语言模型（LLMs）来分析生物技术股票。与许多其他行业不同，生物技术交易主要是事件驱动的：FDA的决策、临床试验结果、安全更新或试验设计的变化都可能导致股票在一天内上涨三倍（[链接](https://www.biotradingarena.com/cases/MDGL_2023-12-14_Resmetirom_NASH)）。 解读这些“催化剂”，通常以新闻稿的形式出现，通常需要具备生物学或医学背景的分析师。听起来“积极”的催化剂，如果出现以下情况，仍然可能导致抛售： - 效果大小低于预期 - 结果仅适用于狭窄的子群体 - 终点指标未能有效降低后期阶段的风险 - 结果未能实质性改变批准的概率 为了探索这一点，我们建立了BioTradingArena，这是一个评估LLMs如何解读生物技术催化剂并预测股票反应的基准。基准测试仅提供催化剂和新闻稿发布前可用的信息（试验设计、先前数据、PubMed文章和市场预期），以测试模型在催化剂发布时预测股票走势的准确性。 目前，该基准包含317个历史催化剂。我们还为特定适应症创建了子集（在肿瘤学中规模最大），因为不同的适应症通常具有不同的模式。我们计划在接下来的几周内向公共数据集中添加更多催化剂。该数据集涵盖不同规模的公司，并创建了调整后的评分，因为大盘生物技术公司的波动性通常远低于小盘和中盘公司。 每行数据包括： - 真实的历史生物技术催化剂（1-3期结果、FDA行动等）及催化剂前一天和当天的定价数据 - 相关的临床试验数据和PubMed PDF 需要注意的是，我们的方法可能存在一些明显的问题。首先，许多临床试验新闻稿可能已经包含在LLMs的预训练数据中。虽然我们尝试通过“去标识化每个新闻稿”并仅提供催化剂日期之前可用的数据来减少这一点，但显然对于这是否足够仍存在一些不确定性。 我们一直在使用这个基准测试提示策略和模型家族。到目前为止，结果喜忧参半，但有趣的是，我们发现最可靠的方法是使用LLMs量化定性特征，然后对这些特征进行线性回归，而不是直接预测价格。 只是想和HN分享这个。我为那些想在沙盒中玩耍的人建立了一个游乐场链接。期待听到一些想法，希望大家能玩得开心！

我整天在审查PR（拉取请求），基本上已经停止仔细阅读它们了。有人提交一个2000行的PR，我只是滚动查看，发现大部分是AI生成的React组件，留个评论，然后合并。我对此感到不安，直到我意识到我团队中的每个人都在做同样的事情。 问题在于差异（diff）的格式不对。一个PR可能会改变三个按钮的行为。盯着绿色和红色的行来理解这一点简直疯狂。 我们构建这个工具的核心原因是，我们觉得今天的产品是基于过去的假设构建的。100倍的代码和相同的审查系统意味着需要100倍的人类关注。人类的注意力无法扩展到满足这种需求，因此我们构建了不同的东西。人们与视频内容的互动明显比与文本内容更为投入。 因此，我们通过强化学习训练并构建了一个代理，它在你打开PR时观察你的预览部署，点击更改的内容，并在PR中发布一个视频。 最困难的部分是找出更改的代码在运行的应用程序中的实际位置。一个差异可能会说Button.tsx第47行已更改，但这并不能告诉你如何找到那个按钮。我们遍历React的Fiber树，每个节点都映射回源文件，因此我们可以追踪到DOM元素的边界框的更改。然后我们对模型在其中展示和互动给予奖励。 显然，这只适用于React，因此在推广到所有语言时我们需要更加聪明。 我们训练了一个强化学习代理与这些组件互动。简单的奖励机制：将修改的内容进入视口得分，点击或输入得双倍分。它大约30%的行为是奇怪的，比如部分表单提交、中途按下Esc键，因为真实用户会这样做，而礼貌的AI模型不会自己测试这些情况。 这可以捕捉到单元测试完全遗漏的内容：z-index错误，即某些东西渲染了但你无法点击，滚动容器将你困住，处理程序静默失败等。 目前存在的问题包括：功能标志、存储不同用户状态，以及任何需要未提供上下文的内容。 欢迎免费试用： [https://morphllm.com/dashboard/integrations/github](https://morphllm.com/dashboard/integrations/github) 演示视频： [https://www.youtube.com/watch?v=Tc66RMA0nCY](https://www.youtube.com/watch?v=Tc66RMA0nCY)

如果您正在寻找工作，请分享您的信息。请使用以下格式： ``` 地点： 远程工作： 愿意搬迁： 技术： 简历： 电子邮件： ``` 请仅在您个人寻找工作时发布信息。代理机构、招聘人员、求职网站等内容不在此讨论范围内。 读者：请仅通过这些电子邮件地址讨论工作机会。 您可以在以下网站搜索这些帖子： [https://www.wantstobehired.com](https://www.wantstobehired.com)。

嗨，HN，我是 Pavel。 我创建 Sklad 是因为作为一名 DevOps 工程师，我对处理操作数据的方式感到沮丧。我经常需要访问 SSH 密码（在无法使用密钥的情况下）、特定的 IP 地址和复杂的 CLI 一行命令。我意识到我把这些信息存储在不安全的文本文件或便利贴上，因为标准的剪贴板管理器感觉太臃肿，而密码管理器对于我的工作流程来说又太慢。 我想要一个“仓库”来存储这些数据——一个可以安静地驻留在系统托盘中，支持深层次的层级结构，完全离线工作，并且外观工业化的工具。 这个应用是用 Rust 和 Tauri v2 构建的。核心技术挑战是将本地 JSON 树结构直接映射到递归的本地操作系统托盘菜单。这使得你可以通过悬停来浏览嵌套文件夹，而无需打开窗口。 为了安全性，我实现了 AES-256-GCM 加密，并使用 Argon2 进行密钥派生。当保险库锁定时，敏感数据会从内存中清除，托盘菜单会收缩到锁定状态。 在 Tauri v2 Beta 生态系统上构建这个应用的过程非常有趣。我很想听听你们对实现的反馈，特别是关于 Rust 端安全逻辑的部分。 代码库： [https://github.com/Rench321/sklad](https://github.com/Rench321/sklad)

你好，HN。 我想首先说明，我是一名开发者，开始这个研究项目是为了挑战自己。我知道像MCP这样的标准协议是存在的，但我想探索一条不同的道路，并享受为桌面应用程序创建专门通信层的乐趣。 这个项目旨在以一种自主的方式处理桌面应用程序之间的通信，因此重点严格放在这个进程间通信（IPC）层上（忘记HTTP API调用吧）。 RAIL（远程代理调用层）的核心有两个基本概念。名字可能听起来有些吓人，但请记住这是一个研究项目： 内存逻辑注入 + 反射 范式转变：聊天是服务器，应用程序是客户端。 为什么采用这种方法？这个想法是避免创建庞大的包装器或API端点，仅仅为了调用内部方法。相反，代理应用程序将其自己的实例传递给SDK（例如，RailEngine.Ignite(this)）。 我发现以下流程非常有趣： - 应用程序将其实例传递给在其自身进程中运行的RailEngine库。 - 聊天（协调者）接收可用方法的清单。模型决定该做什么，并通过命名管道将命令发送回去。 - 触发器：应用程序中的RailEngine接收到命令，并对持有的实例使用反射直接执行.Invoke()。 本质上，我是通过SDK将“代理逻辑”直接注入到应用程序的内存空间中，使聊天能够远程触发本地方法。 关于代码库的说明：GitHub仓库已经变得庞大。核心关注点是RailEngine和RailOrchestrator。你会发现其他连接器（C++、Python），坦率地说，它们是“垃圾代码”或不完整的实验。我在C++中强行使用RTTR实现反射，但对此并不太满意。请跳过这些，它们与架构讨论无关。 我希望能将讨论集中在内存管理语言（如C#/.NET）上，并请教你们： - 架构：这种反转的架构（应用程序通过IPC“拨打回家”）对于本地代理来说，与标准的服务器/API模型相比是否有意义？ - 性能：关于每次调用都使用反射——是否值得在启动时实现一个机制，将方法缓存为委托？还是考虑到LLM本身的延迟，这种优化无关紧要？ - 安全性：由于我们实际上绕过了API层，假设的安全层应该是什么，以防止恶意使用？（例如，用户签名的能力清单？） 我很想听听关于架构的比较和批评。

我建立了一套 webhook 技能，因为 AI 编码代理在 webhook 集成方面的表现令人惊讶地糟糕。生成的代码看起来合理，但一旦运行，就会出现签名验证失败、原始请求体处理错误或中间件顺序破坏一切的问题。 PostHog 对 LLM 代码生成的研究（[链接](https://posthog.com/blog/correct-llm-code-generation)）发现，当代理参考已知有效的示例时，生成的代码更可靠，而不是从训练数据中重构。这就是这里采用的方法。 `webhook-skills` 是基于 Agent Skills 规范（agentskills.io）构建的一套特定于提供商的 webhook 实现和最佳实践指南： ``` - 可运行的示例（目前支持 Express、Next.js、FastAPI，未来将增加更多框架） - 记录了特定于提供商的签名验证注意事项 - 最佳实践模式：幂等性、错误处理、重试逻辑 - 启动时支持 11 个提供商（Stripe、Shopify、GitHub、OpenAI、Clerk、Paddle 等），将根据我的需求或请求进行扩展。 ``` 示例： ``` # 列出技能 npx skills add hookdeck/webhook-skills --list # 安装技能 npx skills add hookdeck/webhook-skills --skill stripe-webhooks --skill webhook-handler-patterns ``` 该工具与 Claude Code、Cursor、Copilot 兼容。这些示例即使没有代理也很有用：您可以直接复制的最小化、经过测试的处理程序。 欢迎提交 PR 以支持新的提供商和框架。我还构建了一个 AI 驱动的生成器，可以自动创建新的提供商技能。只需指向 webhook 文档，它就会研究签名方案，为每个框架生成验证代码，编写测试，并打开一个 PR。