作者认为，模型上下文协议（MCP）曾经是连接大语言模型（LLM）与外部服务的关键，如今已成为一种过时的负担。MCP 最初是为了弥合早期模型能力的不足而开发，但现在随着用户堆叠大量工具服务器，它导致了严重的“上下文臃肿”，迫使开发者为了管理这些服务器而构建复杂的二级基础设施。
作者主张，现代大语言模型已不再需要这些僵化的封装。如今的模型完全有能力自主执行代码、浏览大型代码库，并直接与命令行界面（CLI）和原始 HTTP API 进行交互。通过利用现有的标准（例如使用 `Accept` 标头从网站请求 Markdown），智能体无需 MCP 特定的架构开销，即可获取所需的数据。
归根结底，本文呼吁废弃 MCP。与其维护多余的服务器层，不如将重点转向标准化智能体如何通过成熟的现有网络协议直接与互联网交互。通过将浏览器和终端作为主要接口，我们可以迈向一个更简洁、更强大的智能体未来。
每日HackerNews RSS
这场讨论反映了围绕“模型上下文协议”（MCP）的激烈争议。
**批评者**认为，MCP 是一种过度设计且具有“状态”的迂回方案，会消耗过多的 Token。他们主张，传统方法（如文档完备的 REST API、OpenAPI 规范和命令行工具）更加灵活、久经考验且对 Token 更友好。许多人认为，沙盒化的命令行环境为智能体任务提供了更稳健、“符合 Unix 哲学”的路径，且通过定制的智能体框架，无需复杂的新协议也能实现同样的安全性与可审计性。
**支持者**则坚持认为，对于安全性、治理和集中式访问控制至关重要的企业与团队环境而言，MCP 是必不可少的。其核心论点包括：
* **安全性：** 它提供了一种确定性的方式来隔离 API 密钥与敏感服务，防止“盲目”访问。
* **发现与标准化交互：** MCP 为智能体提供了一个统一的接口来发现能力、工具和资源，从而减少了幻觉以及在查阅 API 文档上浪费的时间。
* **企业集成：** 它允许服务提供商在不向智能体授予原始、不受限访问权限的情况下，安全地暴露内部数据。
总而言之，尽管许多独立开发者更倾向于简单的 CLI 或基于 API 的解决方案，但 MCP 正作为一种必要的“适配器”，在企业级的智能体与服务集成领域日益获得认可。
本文档概述了一种模块化的 seccomp 策略配置，其灵感源自 Docker 的默认配置文件，旨在为注重安全性的应用程序提供沙盒保护。该设计的主要目标如下： * **最小化攻击面**：策略排除了需要 root 权限的系统调用，以减小 BPF 程序的大小并降低开销。 * **防御指纹识别**：省略了常被用于系统分析或桌面环境指纹识别的罕用系统调用。 * **模块化架构**：系统调用被分类为细粒度的功能模块（例如 `IoEvent`、`NetworkIo`、`Credentials`），该设计参考了 systemd 的过滤集和 OpenBSD 的“pledge”机制。 该结构强化了职责分离，例如区分基础 I/O 与文件系统修改，或区分网络服务器操作与客户端套接字。它还包含用于处理特定架构怪癖（如 x86 ABI 模拟）的“兼容性（Compat）”策略，并为沙盒（`landlock`、`seccomp`）和资源管理等关键安全任务提供了明确的类别。通过将系统调用组织成这些逻辑组，该配置能够实现精细、易于维护且高效的安全过滤器，适用于非特权用户。
抱歉。
V1 alpha — 自 2026 年 8 月起在测试台上运行。papyDeck 的游玩体验如同街机，而开发体验如同文本编辑器。其上的每一款游戏都是一段 Lua 脚本，你可以阅读、修改和重写——包括他人编写的游戏。打开模拟器 ↗ 查看开发板 阅读规范
抱歉。
客户端挑战：您的浏览器已禁用 JavaScript。请启用 JavaScript 以继续。本站的一个必要组件无法加载。这可能是由于浏览器插件、网络问题或浏览器设置所致。请检查您的连接、禁用广告拦截器，或尝试使用其他浏览器。
这场 Hacker News 讨论聚焦于美国政府废除发电厂气候污染限制的举措。对话凸显了在能源政策、气候责任和地缘政治方面存在的尖锐分歧。
**支持废除的观点**通常优先考虑短期经济稳定和工业竞争力。这些法规的批评者认为，昂贵的气候指令阻碍了美国经济发展，迫使生产转移至中国和印度等国家，且其所依赖的技术在经济上尚不可行。一些参与者认为，“气候污染”是一个政治化的术语，被用来过度行使监管权力。
**反对废除的观点**强调了长期的战略和经济风险。这些法规的支持者主张，全球经济正转向可再生能源，其成本日益降低且比化石燃料更可靠。他们认为，此举削弱了美国的“软实力”，无视了气候变化的现实，并通过维持对波动剧烈的化石燃料市场的依赖，使美国陷入战略上的脆弱境地。
最后，这场辩论触及了全球能源转型的复杂性——指出虽然中国是新建燃煤电厂最多的国家，但同时也在可再生能源部署方面领先全球，这体现了一种复杂的能源安全双轨策略。
请启用 JavaScript 和 Cookie 以继续。
Hacker News
最新
|
往期
|
评论
|
提问
|
展示
|
招聘
|
提交
登录
格洛斯特大教堂及城市教堂的报时机器历史 [pdf]
(
bgas.org.uk
)
7 点积分
由
dvt
1 天前
|
隐藏
|
往期
|
收藏
|
讨论
帮助
指南
|
常见问题
|
列表
|
API
|
安全
|
法律
|
申请 YC
|
联系
搜索：
这份摘要梳理了截至 2026 年 9 月的自托管大语言模型（LLM）编排工具，旨在帮助用户根据硬件配置和运维需求做出选择： * **单机/易用性：** **Ollama** 是笔记本电脑或单台桌面设备的标准方案。若仅需单进程部署单个模型，**vLLM** 和 **llama.cpp** 是性能更优的后端选择。 * **Apple Silicon：** **exo** 是 Mac 集群的首选，通过基于 Thunderbolt 5 的 RDMA 技术实现可扩展性能。 * **企业/部门级：** **GPUStack** 和 **Xinference** 提供了共享硬件所需的 Web 控制台、API 密钥管理、计量及多用户支持。 * **通用/广泛性：** **LocalAI** 对非 LLM 模态（音频、图像、视频）的支持最为广泛，并具备健壮的 P2P 联邦架构。 * **基础设施/扩展性：** **SkyPilot** 和 **dstack** 擅长作业调度及云端算力突发；而 **NVIDIA Dynamo/llm-d** 专为基于 Kubernetes 的高端数据中心架构设计。 * **混合/进阶：** **CoderAI** 是一款多功能终端，支持多模态分发、带价格上限的本地到云端算力突发，以及分布式 LoRA 训练。 **LiteLLM** 依然是用于多个端点间的路由和成本追踪的核心工具，而非直接运行模型的框架。
这篇 Hacker News 讨论帖涉及一篇对比自托管推理编排工具（LocalAI、exo、GPUStack 和 vLLM）的博文。
博文作者“nextime”随即遭到社区成员的批评，他们准确地指出该文章由人工智能生成。多名用户指出了文中生硬的语气，并质疑了其中的技术不一致之处，例如关于 LiteLLM 的标题令人困惑。
作者承认该帖是意外发布的一篇未完成的测试稿。他为未能监管好自动化流程致歉，并表示该文章原本无意以未编辑的状态发布。该讨论帖简要地反映了社区识别 AI 生成内容的速度，以及作者随后对技术失误的承认。
2026 年，人工智能驱动开发的快速演进要求我们不断适应。在 Imprint，我们已从简单的 AI 编码助手转型为复杂的“软件工厂”模式。 这种模式超越了基于任务的 AI，转向了以目标为导向的自动化。我们的“工厂”利用一套循环架构，对项目 RFC 进行审计，通过 Datadog 和 Snowflake 监控指标，并管理 Linear 工单。智能体能够自主创建必要文档、识别缺失任务并执行代码编写工作，仅在需要更新项目目标时才会暂停进行同步。 这种方法解决了“状态囤积”问题，即开发者无意中将重要的项目背景保留在脑海中，而非系统中。通过整合数据可视化、集中式任务管理（Linear）以及受控的智能体集群，该工厂确保智能体不仅能编写代码，还能验证工作是否与高层商业目标保持一致。 归根结底，这些进步是相辅相成的：软件工厂之所以成功，是因为我们在通用任务管理和跨代码库工作空间等基础设施上进行了投入。尽管变革的节奏令人疲惫，但它代表了软件在发布后构建、管理和监控方式的根本性转变。
围绕“软件工厂”模式——即利用人工智能体实现软件开发自动化——的讨论，在开发者群体中引发了热议，既有追捧，亦有质疑。
支持者使用 AI 智能体及 Grok 或 Claude 等工具来管理任务、生成代码并简化工作流程。他们认为，这能显著加快开发速度，特别是在小型项目或静态网站开发中，让个人能够指挥由智能体组成的“开发团队”。
然而，许多批评者提出了重大担忧：
* **质量与可维护性：** 人们担心这种方法会产生“AI 垃圾”，导致巨额技术债和缺乏经验丰富的工程师把关的“糟糕”代码库。
* **组织风险：** 在企业环境中，通过 AI “绕过流程”可能导致系统不稳定和质量参差不齐，因为智能体往往缺乏处理复杂或细微需求所需的判断力。
* **实用性：** 许多评论者认为，“软件工厂”与其说是一种正式模式，不如说是一场管理实验。批评者指出，智能体在用户界面（UI/UX）设计上表现不佳，容易出现“管中窥豹”的问题，且必须有人工参与监督，以防止项目出现灾难性的偏离。
归根结底，目前的共识是，尽管 AI 可以处理基础任务，但在长期架构设计、质量保证和高层产品策略方面仍显不足。
我常犯错 I am often wrong
27 天前
作者概述了一套用于产品开发的一贯性、迭代式问题解决方法：搜集信息、界定问题、确立简易方案、设定目标以及采取紧急行动。由于该过程依赖于在获取新数据时更新个人的“先验知识”，作者认为由此产生的“反复折腾”或波动是寻找正确解决方案中健康且必要的组成部分。 最常见的失败模式发生在问题或方案定义不清时，这会导致不必要的复杂化。为了缓解这一问题，作者强调了持续反馈循环和实时协作的重要性。最终，作者拥抱错误，将其视为完善认知、加速学习并实现更清晰、更有效成果的宝贵催化剂。
这篇 Hacker News 讨论聚焦于 Boris Cherny 的一篇博文，文中他概述了一个六步问题解决框架：理解问题、过度构建解决方案、推销方案、与他人迭代以简化方案、推卸责任、说服专家解决问题，最后居功自傲。
社区反应极为负面，许多用户认为该框架是“硅谷陈词滥调”或“企业心理变态”的体现。主要争议点包括：
* **管理风格：** 批评者认为，强迫员工遵循个人的、僵化的框架属于微观管理，并且在强调“紧迫感”的同时，会营造出一种有毒的工作环境。
* **虚伪：** 许多用户认为标题“我经常犯错”是一种表演性的“假谦虚”，或者是掩盖缺乏真正反思的肤浅亲和尝试。
* **产品质量：** 一些评论者借此机会发泄对“Claude Code”质量的不满，提到了持续存在的漏洞、迟缓的性能，以及该团队在处理社区反馈时表现出的傲慢态度。
* **回音室效应：** 讨论表明，“AI 炒作”文化往往导致领导者优先考虑肤浅的思想领导力，而非构建可靠的、以用户为中心的软件。
本仓库提供了任天堂 GameCube 版《生化危机 4》“2004 年 11 月 25 日”调试版本的完整、字节一致的反编译代码（G4BE08）。本项目成功重现了 `main.dol` 及全部 114 个 REL 覆盖文件，与原始二进制文件完全匹配。 该代码库包含约 55 万行 C/C++ 源代码，是使用原始编译器（SN Systems GCC 2.95.3 和 Metrowerks CodeWarrior）重构而成的。为了实现字节级的完美一致，本项目利用了特定的编译器匹配技术并记录了寄存器使用情况，同时尽可能避免使用指令级汇编。仅存的少量汇编单元反映了原作者为硬件特定内核编写底层代码的习惯。 本项目不包含任何游戏资源或受版权保护的代码；用户需自行提供光盘镜像以构建仓库。项目中包含丰富的验证工具，包括字节级比对、符号映射和动画导出。此工作仅用于研究与保存目的，所有自定义工具及文档均基于 CC0 协议发布。
最近，一篇展示《生化危机 4》GameCube 版本实现完全字节级一致的 C/C++ 反编译的 Hacker News 帖子，引发了关于人工智能在复古游戏保护中作用的热烈讨论。
该项目凸显了逆向工程的技术复杂性，一些贡献者指出，为了实现与原始二进制文件的精确匹配，代码有时不得不依赖“黑客手段”，例如空汇编锚点或强制寄存器锁定。这导致社区观点出现了分歧：
* **支持 AI 的观点：** 支持者认为 AI 是不可或缺的工具，它能加速繁琐的任务，帮助经验不足的开发者跨越技术门槛，并通过实现现代移植、漏洞修复和无障碍模组，使游戏更易于获取。
* **纯粹主义者的观点：** 批评者认为，反编译的核心价值在于学习过程——即理解系统架构和底层硬件限制的“深度工作”。他们担心 AI 辅助的项目跳过了这些必要的教育体验，可能会削弱社区的专业积累。
尽管关于分发衍生源代码的法律影响尚存争议，但这场讨论凸显了复古游戏社区在处理传统逆向工程工艺与现代自动化工具的结合时，正发生着转变。
**jevchat** 是一个实验性的、高度可定制的聊天界面，通过要求 Jev 模型预测序列中的下一个符号来生成文本。该工具通过从概率分布中反复采样，逐个字符或标记地构建响应，直到达到停止信号。
该项目提供了多种查询模型的策略，从简单的 **choice**（请求下一个符号）到 **bisect**（使用是非拆分）以及 **buckets**（管理大型词汇表）。用户可以切换字母表、采样策略和展示模式——例如“假设”模式，该模式通过让模型对完整的字符串而非孤立的符号进行排序，显著提高了准确性。
尽管运行起来既不切实际且成本高昂，但该工具专为娱乐和实验而设计。用户可以通过实时终端界面进行交互，该界面会显示实时的生成统计数据和概率分布。代码库经过充分测试，提供了用于性能比较的 `bench` 命令，并可通过 `.env` 文件进行灵活配置。
最近在 Hacker News 上，一位用户分享了他利用 Jev 构建“糟糕”聊天机器人的实验，引发了关于人工智能开发本质及大语言模型（LLM）实验当前趋势的热烈讨论。
参与者将该聊天机器人反复试验的行为比作《瑞克和莫蒂》中的“死亡水晶”场景，并指出，业余爱好者将此类概念转化为项目的高速模式，营造出了一种竞争激烈、“快节奏”的氛围。尽管一些用户认为该项目是微不足道或“毫无意义”的练习，但另一些人则为其辩护，认为这是必经的过程，也是了解模型底层架构的宝贵途径。
讨论重点突出了以下几个主题：
* **性能与效率：** 虽然主流大语言模型功能更强大，但 Jev 提供的速度和成本效益对特定的小众用例更具吸引力。
* **人工智能的“杰文斯悖论”：** 用户指出，工具的快速进步导致了“跑分至上”和实验性代码的激增，且往往是在重复过去的迭代。
* **递归式调试：** 该讨论还涉及了利用一个大语言模型去解释或调试另一个大语言模型的元体验，并将其比作“给狗按按钮”。