你好，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。
最初是行动运行器未能接收新任务，现在已经扩展到其他服务。 - https://www.githubstatus.com/<p>之前无法发布此信息，因为它被标记为上个月事件的重复。
关于加州预算和一些提议的税收政策，已经进行了很多讨论，因此我请Claude Code对预算进行研究，并将其转化为一个互动仪表板。
通过使用异步子代理，Claude能够同时研究大约十个预算项目，涵盖多个年份，为像我这样对预算了解不多的人提供了大量有用的背景信息和图表。
虽然在前端更改方面仍然存在一些困难，但在研究方面，这大约提高了我20到40倍的工作效率。
如果你有任何想要添加的额外数据或可视化内容，请告诉我！
我在修改我的提案答辩时，总感觉自己在重复同一个术语。在一个通常由多个 .tex 文件组成的 LaTeX 项目中，想要快速、干净地查看词频而不需要将所有文件合并在一起，或者将 LaTeX 命令/数学公式算作“单词”，是相当麻烦的。
因此，我构建了 latex-wc，这是一个小型的 Python 命令行工具，具有以下功能：
- 从 LaTeX 中提取词元，同时忽略常见的 LaTeX “噪音”（命令、注释、数学公式、引用/文献等）
- 可以处理单个 .tex 文件或一个目录，并递归扫描所有 *.tex 文件
- 一次性打印综合报告（总词数、独特词数、前 N 名频率）
尝试它的最快方法是 `uvx latex-wc [路径]`（文件或目录）。欢迎反馈，特别是关于你认为启发式过滤器过于激进或不够激进的边缘案例。
嘿，HN！我上周参加了一个ATProto的聚会，作为一个对学术出版感到厌倦的半学术人士，我觉得有一个很酷的机会可以在Octopus（<a href="https://www.octopus.ac/" rel="nofollow">https://www.octopus.ac/</a>）的基础上进行开发，所以我在周末有点兴奋，构建了Octosphere。<p>希望你们中的一些人会觉得它有趣！博客文章在这里：<a href="https://andreasthinks.me/posts/octosphere/octosphere.html" rel="nofollow">https://andreasthinks.me/posts/octosphere/octosphere.html</a>
我在过去几周一直在使用Clawdbot，确实觉得它很有用，但运行它让我感到非常紧张。<p>OpenClaw有52个以上的模块，并在一个Node进程中运行具有近乎无限权限的代理。NanoClaw的核心代码大约有500行，代理在实际的Apple容器中运行，并实现文件系统隔离。每个聊天都有自己的沙盒上下文。<p>这不是一把瑞士军刀。它是根据我的具体需求而构建的。你可以分叉它，做成你自己的版本。