返回首页
最新
Postman悄然取消了免费多用户协作功能，并将免费计划限制为单用户。这对小团队、学生和开源贡献者的影响最大，这很讽刺，因为正是这些用户帮助Postman成为了默认选择。我们决定不再支付费用，而是转用了其他工具，最终选择了Apidog，它集成了API设计、测试和文档，并且仍然支持团队工作流程。很想听听其他人是如何应对的，是选择付费、迁移，还是自己搭建环境？
我构建了一个可启动的Linux发行版，将人工智能视为系统原语——就像CPU或内存一样。该系统专为数据不能离开网络的安全敏感环境设计。
问题：大多数人工智能需要云API，这意味着您的数据将失去控制。对于银行、医疗、国防和受监管行业来说，这根本不可行。
解决方案：EdgeAI-OS在本地运行所有内容。没有云调用，没有API密钥，没有遥测。启动ISO，使用人工智能。您的数据永远不会离开机器。
安全特性：
- 100%离线操作——适合空气隔离，零网络依赖
- 无外部API调用——所有推理在CPU上本地运行
- 命令风险评估——每个命令被分类为安全/中等/危险
- 危险模式阻止——防止执行rm -rf /、curl|bash、fork炸弹等
- 开源且可审计——MIT许可证，检查每一行代码
- 无数据外泄——绝不向外发送任何信息
ISO中包含的内容：
- 本地LLM（TinyLlama 1.1B + SmolLM 135M）——在CPU上运行，无需GPU
- ai-sh：自然语言命令行，80%的查询通过模板瞬间解决
- 多层路由：简单查询→快速模型，复杂查询→更大模型
示例ai-sh会话：
现在几点了？
[模板] date ← 即时，无需LLM
文件大于1GB
[模板] find . -size +1G ← 即时，无需LLM
rm -rf /
[危险] 被阻止 ← 安全检查
将nginx配置为反向代理
[ai生成] ... ← 使用本地LLM（约1-2秒）
目标使用案例：
- 空气隔离的企业环境（银行、医疗、政府）
- 国防与机密网络
- 无互联网连接的边缘设备
- 注重隐私的开发者
- 合规要求高的行业（HIPAA、GDPR、SOC2）
基于Rust构建，基于Debian。推荐4GB RAM。
GitHub: [https://github.com/neuralweaves/edgeai-os](https://github.com/neuralweaves/edgeai-os)
ISO下载: [https://github.com/neuralweaves/edgeai-os/releases](https://github.com/neuralweaves/edgeai-os/releases)（1.2GB）
非常希望获得反馈，尤其是来自安全/受监管环境工作的人员。哪些功能会让您觉得这个系统适合企业使用？
从Seti@home开始，到比特币……现在在我的电脑上以管理员权限运行AI Slop命令……也许OpenAI可以在我的电脑上运行工作负载，并为我做他们的工作支付一些报酬？
npx agentseed init
AGENTS.md（<a href="https://agents.md" rel="nofollow">https://agents.md</a>）是一个标准文件，用于AI编码代理理解代码库（技术栈、命令、约定）。
Agentseed通过静态分析直接从代码库生成该文件。支持可选的LLM增强，您可以使用自己的API密钥。
它提取语言、框架、依赖项、构建/测试命令、目录结构以及单体仓库的边界。
Vibe 为我的 Omarchy 设置编写了这个代码。希望分享并听听大家的想法。
我在过去几个月里一直在构建MCP服务器，发现为AI代理设计工具架构与为人类设计REST API有着惊人的不同。
以下是一些在生产中有效和无效的模式：
**无效的模式：**
1. 细粒度的CRUD端点。我最开始使用了显而易见的端点，如get_request、update_request_status、update_request_assignee、add_comment等。代理经常会调用错误的端点或以错误的顺序链式调用。过多相似的工具导致了混淆。
2. 泛化的参数名称。一个名为“id”的字段在没有上下文的情况下对代理毫无意义。它会产生虚假的ID或传递错误实体的ID。
3. 稀疏的错误信息。返回“404 Not Found”并没有给代理提供任何有用的信息。它会无限期地重试同样的错误调用。
**有效的模式：**
1. 更少、更宽泛的工具。与其使用8个CRUD端点，不如将它们合并为3个：search_requests、get_request_detail、update_request。使用更小的工具集，代理犯错的次数大大减少。
2. 带有示例的描述性架构。在JSON架构中添加“description”字段及示例值显著提高了准确性。架构本身就是提示。
3. 丰富的错误响应。与其返回“404”，不如返回“未找到ID为‘abc’的请求。您是否想先进行搜索？可用工具：search_requests”，这实际上促使代理自我纠正。
4. 读-写模式。在结构化工具时，让代理在进行更改之前自然地获取上下文，显著减少了破坏性错误。
5. 危险操作的确认字段。为删除或批量更新添加一个必需的“confirm: true”参数，起到了减速带的作用，使代理三思而后行。
**思维模型的转变：** 你不是在为阅读文档的开发者设计API，而是在为一个只看到架构和最后几条消息的推理引擎设计接口。每个字段名称、描述和错误信息都是一个提示。
我很好奇其他构建MCP服务器的人是否发现了类似的模式或不同的方法。