最新

我开发了一款AI工具，通过冷邮件申请工作，因为LinkedIn的快速申请功能对我没有帮助。大多数申请都消失在ATS筛选中，因此我想要一个能够直接向公司或人力资源发送个性化申请的工具。 该工具从你的简历中提取信息，将其与职位描述匹配，按照你的风格撰写个性化邮件，并自动查找公司邮箱，或者让你自行设置。然后，它会通过你的个人邮箱发送附有简历的邮件。 该工具有两种模式： 快速模式使用LinkedIn搜索结果，而CSV模式则允许你上传职位列表，并一次性申请所有职位。 我最初是为自己开发的，但决定分享出来，希望能帮助到那些面临同样困扰的人。欢迎大家提问或反馈意见。

我构建了一个RAG应用程序，用于检索与伦理困境相关的《博伽梵歌》经文，并生成结构化的指导。 问题： 《博伽梵歌》共有701节经文。为特定情境寻找适用的智慧需要深入的熟悉或数小时的阅读。 工作原理： 1. 用户描述他们的伦理困境 2. 使用句子转换器嵌入查询 3. ChromaDB检索出语义上最相似的前k节经文 4. LLM生成结构化输出：提供3个选项及其权衡、实施步骤和经文引用 技术栈： - 后端：FastAPI、PostgreSQL、Redis - 向量数据库：ChromaDB，使用all-MiniLM-L6-v2嵌入 - LLM：主要使用Ollama (qwen2.5:3b)，备用使用Anthropic Claude - 前端：React + TypeScript + Tailwind 关键设计决策： - 使用RAG防止幻觉——每个推荐都引用实际经文 - 信心评分标记低质量输出以供审核 - 结构化JSON输出以确保一致的用户体验 - 本地LLM选项以保护隐私并实现零API成本 我学到的： - LLM的JSON提取比预期的要困难。构建了一个三层备用方案（直接解析 → markdown块提取 → 原始解码扫描） - 对宗教文本的语义搜索在伦理查询中表现出乎意料的好 - 较小的模型（3B参数）在良好的提示和检索上下文的约束下表现良好 GitHub: [https://github.com/geetanjaliapp/geetanjali](https://github.com/geetanjaliapp/geetanjali) 欢迎讨论RAG架构或提供反馈。

嗨，HN， 在过去的几个月里，我一直在开发IntentusNet，这是一个小型、语言无关的运行时，用于在代理和工具之间路由“意图”，并支持可选的加密和多种传输方式。 GitHub: [https://github.com/Balchandar/intentusnet](https://github.com/Balchandar/intentusnet) ### 这个项目试图解决的问题 我看到的大多数多代理/工具调用设置最终都变成了大量的临时拼凑： - 各个代理之间的自定义消息格式 - 手动编写的路由和回退逻辑 - 在一个地方使用HTTP，在另一个地方使用WebSocket，可能在其他地方使用ZeroMQ - 没有一致的追踪或错误模型 - 没有明确的地方添加安全性（加密、来源、身份链） MCP非常适合描述工具，但它并不试图成为一个运行时或路由器。我想要一些可以在MCP及其他技术栈之下或旁边工作的东西，能够简单回答： “给定一个意图，哪个代理应该处理它，使用哪种传输方式，采用什么回退机制，以及我们如何安全地封装它？” ### IntentusNet提供的功能（当前） 在核心部分，它有几个小的基本组件： - **IntentEnvelope** – 结构化消息，包含上下文、元数据、路由选项和标签 - **AgentRegistry** – 内存中代理和能力的注册表（它们处理哪些意图，可选的回退链） - **IntentRouter** – 选择一个代理，执行它，并在主要代理失败时应用回退 - **Transports** – 可插拔的传输方式，目前包括： - 进程内（直接路由调用） - HTTP（带有TransportEnvelope的POST请求） - WebSocket（双工、异步） - ZeroMQ（REQ/REP客户端加上简单服务器） - **Tracing** – 简单的追踪接收器，记录跨度（代理、意图、延迟、状态、错误） - **EMCL（加密模型上下文层）** – 可选的信封： - 一个基于HMAC的简单演示提供者 - 一个AES-GCM提供者（AES-256-GCM，base64，身份链）用于真正的加密 此外，还有一个MCP适配器，它接受MCP工具请求（{ name, arguments }），将其封装到IntentEnvelope中，通过IntentusNet路由，并返回MCP风格的结果。这个想法是MCP工具可以通过同一个路由器连接，无论是否使用EMCL。 ### 示例用法 一个最小的流程如下： - 定义具有“summarize.document.v1”、“translate.text.v1”、“store.note.v1”等能力的代理 - 在运行时注册它们 - 使用IntentusClient发送一个带有有效载荷的意图；路由器选择合适的代理，并在配置的情况下处理回退 还有一个小型“助手”风格的设置示例，其中一个类似NLU的代理解析自然语言请求，并向专门的代理（如日历、地图等）发出下游意图，以展示多代理路由的实际应用。 ### 状态/缺失的内容 这是一个早期阶段的项目： - 运行时使用Python；其他SDK（例如C#）尚未准备好 - 编排/工作流层（序列、并行步骤、分支）在RFC中进行了初步勾勒，但仅部分实现 - 文档和示例确实可以改进 - 目前尚未声明生产就绪：这更像是一个结构化的参考实现或起始点 我非常希望能收到关于以下方面的反馈： - 架构（协议、路由器、传输、EMCL之间的分离是否合理？） - 这种类型的意图路由器在您正在构建的MCP或基于工具的系统中是否真的有用 - 您期望在这样的运行时中看到的缺失基本组件（超时、背压、更丰富的追踪等） - 在现实世界的工作流中，小型、传输无关、支持EMCL的路由器将如何提供帮助（或在什么情况下显得过于复杂） 如果您正在使用MCP、多代理设置或安全工具调用，并对这个项目的运作方式有意见，我非常希望听到您的想法——无论是在这里，还是通过GitHub上的问题或PR。

我是一个创始人（也是前建筑师），正在构建一个物流操作系统。最近，我收到了反馈，称我的网站看起来“便宜且丑陋”，因为我使用了衬线字体和雕刻风格的美学，而不是标准的无衬线“清洁科技”外观。 我的初衷是想营造一种“探索时代”的氛围，因为人工智能时代感觉像是在开辟未知的领域。但用户似乎习惯于只信任“标准蓝色SaaS用户界面”。 我想问HN：一个B2B工具是否必须遵循“标准现代用户界面”才能被认真对待？还是在企业软件中还有空间容纳独特甚至可能引发争议的美学？ 我正在考虑是妥协重新设计成“无聊但安全”，还是坚持我们的灵魂。希望听听你们对“品牌独特性与用户界面熟悉度”的看法。