技术

Harness工程不能保证AI永远不走偏，但它能把AI从'自由发挥的概率模型'，变成一个'有边界、可验证、可审计、可恢复的工程系统'。

模型之外的那个「执行环境」，才是决定任务能否跑完的真正变量。

作为独立开发者，我为什么选择 Eino 来构建 AI 应用（Go语言） 独立开发者做 AI 应用，最怕两件事：一是踩坑，二是被框架绑架。 踩坑意味着你花了两周搭的系统，上线后发现根本撑不住并发，或者调试起来像开盲盒；被框架绑架意味着框架的每一次大版本更新都是你的加班夜。 我花了一段时间评估了几个主流选项，最后在自己的项目里选了 Eino。说说理由。我使用的 Eino 版本如下： github.com/cloudwego/eino v0.8.13 你一个人，精力是最稀缺的资源 独立开发者和公司团队最大的区别，不是技术水平，而是精力分配。你同时要管产品、设计、开发、运营，留给"研究框架"的时间极其有限。 这就是为什么框架的设计哲学对你来说比对大公司更重要。一个设计混乱的框架，会把你困在细节里；一个设计清晰的框架，让你专注在真正重要的事上。 Eino 的核心设计思路很简单：把能力拆成组件，把流程描述为图，框架处理所有脏活。 你需要一个 RAG 系统，就把检索、提示词、模型调用几个节点连起来；你需要一个能用工具的 Agent，就把工具注册进去，Agent 的循环调用逻辑框架全包了。 你不需要理解流式数据如何在节点间传递，不需要手写工具调用的解析循环，不需要自己实现多轮对话的上下文管理。这些都是框架该做的事，Eino 做了。 字节跳动帮你提前踩过坑 独立开发者最大的风险之一，是用了一个没有生产验证的框架。看起来文档漂亮，demo 跑得顺，真到线上就各种奇怪问题——并发时状态串了，流式输出在特定场景下卡住了，Token 超限时框架直接崩了。 Eino 在字节跳动内部跑了超过半年，支撑着豆包、TikTok 这类亿级用户的产品。这不是说拿来炫耀的背书，而是一个工程上的实际意义：那些你独自开发时可能要花几个月才踩到的边界 case，字节内部的工程师已经踩过了，并且修掉了。 你站在他们的肩膀上出发，少走很多弯路。 Go 语言是独立开发者的好朋友 很多 AI 框架是 Python 的，Python 当然没有问题，但如果你的后端是 Go 写的——或者你打算用 Go——那嵌入一套 Python 框架会带来真实的运维成本：两套依赖管理、两个运行时、两种调试工具。作为一个人，你付不起这个代价。 Eino 是原生 Go 框架，跟你现有的 Go 服务深度集成，单二进制部署，没有额外的运行时负担。Go 的强类型也意味着很多错误在写代码时就被发现，而不是到线上才暴露——对于没有 QA 团队的你，这一点格外重要。 你不用从零开始集成所有东西 独立开发者做 AI 应用，通常需要接入：某个大模型 API、某个向量数据库、某个可观测性工具。每接一个，都要读一遍 SDK 文档，写一堆胶水代码。 Eino 的扩展库（EinoExt）已经帮你把这些都做了。OpenAI、Claude、Gemini、豆包 Ark、Ollama，开箱可用；Elasticsearch 等向量存储，直接接；OpenTelemetry 的 Tracing，一行配置。你换模型供应商不需要改业务代码，换向量库也一样——因为 Eino 的组件接口是统一的，实现是可替换的。 ...

很多团队做 AI 产品，第一阶段都很顺利： 调通一个模型； 写几个 API； 跑出一个 demo。 但到了第二阶段，问题会集中爆发： 客户要稳定，单一上游不稳定； 成本要可控，调用量上来后账就乱了； 用户要分层，个人、团队、管理员权限都不一样； 运营要可视，出了问题要知道是谁、哪个 key、哪个渠道、哪个模型； 商业要闭环，充值、订阅、额度、结算要打通。 这时你会发现，真正难的不是“会调模型”，而是“把模型能力做成一个能长期运营的系统”。 我这几天把 new-api 关键代码路径完整过了一遍，结论是：它的价值不在于“支持 40+ 上游”这句话本身，而在于它把 AI 网关最难的工程问题做成了一整套闭环。 这篇文章我不做功能清单，而是按“工程决策”的视角，讲我为什么推荐它。 典型请求链路 客户端 ↓ /v1/chat/completions 或 /v1/messages ↓ 认证 TokenAuth / UserAuth ↓ 限流 ModelRequestRateLimit ↓ 分发 Distribute ↓ Relay 进行请求校验、token 估算、预扣费 ↓ Adaptor 转换上游格式并请求 provider ↓ DoResponse 解析 usage 与流式结果 ↓ Settle / Refund 完成结算或退款 先说结论：new-api 适合什么团队？ 如果你符合下面两条以上，我建议认真评估 new-api： ...

使用 ChatGPT 修复 QNAP QuMagie 相册不显示照片的问题 最近处理了一次 QNAP NAS 上 QuMagie 相册无法显示照片的问题。表面现象很迷惑：照片和视频明明在 File Station 里能看到，Multimedia Console 也显示已经完成索引，但 QuMagie 页面里却始终是空的。 这篇文章记录完整排查和修复过程。为了保护隐私，文中的 NAS 地址、账号、真实共享目录、家庭成员姓名、照片路径都做了替换。示例目录和账号仅用于说明问题，不对应真实环境。 问题现象 NAS 上有一个用于存放家庭照片的共享目录，本文用下面这个名字代替： 家庭照片/ QuMagie 的内容来源也已经添加了这个目录。登录 QuMagie 后，页面提示： 此内容源文件夹中没有可用的照片或视频。 此内容源文件夹可能为空，您的访问权限不足，或文件当前仍在处理中。 但其他地方看起来都正常： File Station 可以看到照片和视频。 使用同一个 NAS 账号可以进入目录。 Multimedia Console 里显示照片、视频、缩略图、人物识别、物品识别等任务都已有索引。 QuMagie 内容管理里也能看到这个来源目录。 这类问题很容易让人以为是“权限不足”或“索引还没跑完”。但这次真正的问题并不是文件不存在，也不是普通意义上的权限不足，而是 QuMagie 的共享目录权限路径和 Multimedia Console 的索引路径不一致。 为什么请 ChatGPT 参与排查 这次我没有把 ChatGPT 当成一个简单问答工具，而是把它当作一个排障协作伙伴来用。 整个过程里，ChatGPT 帮我做了几件事： 把现象拆成 File Station、Multimedia Console、QuMagie UI、QuMagie API、底层路径几个层面。 避免直接做破坏性操作，先验证再处理。 设计迁移方案，确保照片和视频不丢。 识别 NAS 自动生成的缩略图、回收站、快照目录，避免污染新相册。 最后通过数量校验和 QuMagie API 确认修复有效。 对 NAS 这类“UI 看起来正常，但底层路径很绕”的问题，单靠界面判断经常不够。ChatGPT 的价值主要是帮助我把排查流程变得更系统。 ...

【AI前沿观察】2026-05-14 日报 自动生成于 2026-05-14 23:00 📊 今日推送概览 共推送 1 条重要资讯。今日整体行业动态相对平静，OpenAI 在 Agent 安全基础设施方面持续发力。 🔵 AI 领域 Building a safe, effective sandbox to enable Codex on Windows 事实：OpenAI 发布技术博客，详细介绍了为 Codex（代码 Agent）构建 Windows 沙箱的技术方案。该沙箱旨在让 Codex 能够安全地在 Windows 环境中执行代码操作，同时防止恶意行为和越权访问。这是 Codex 从 macOS/Linux 扩展到 Windows 的关键一步。 思考：Codex 作为 OpenAI 的旗舰代码 Agent 产品，其核心挑战不仅仅是"能写代码"，更在于"安全地执行代码"。沙箱技术是 Agent 从实验室走向生产环境的必备基础设施。扩展到 Windows 意味着 Codex 正在覆盖全球最大的开发者群体——企业级 Windows 开发环境。这背后体现的是 OpenAI 对 Agent 安全边界的深思熟虑：不是简单地限制功能，而是通过精细化的沙箱隔离，在安全性和可用性之间找到平衡。结合此前"Running Codex safely at OpenAI"的博客，可以看出 OpenAI 正在系统性地构建 Agent 安全框架，这为其未来的企业级部署铺平道路。 📌 今日核心洞察 Agent 安全成为 AI 公司的核心竞争力：OpenAI 连续发布 Codex 安全相关博客，从总体安全策略到具体平台的沙箱实现，表明"安全地运行 Agent"已经成为 AI 公司从技术演示走向企业级产品的关键门槛。谁能更好地解决 Agent 的安全问题，谁就能更快地占领企业市场。 ...

🚀 核心发布信息 模型名称：Claude Opus 4.7 定位：Opus 4.6 的直接升级版，但能力不及最强模型 Claude Mythos Preview 定价：与 Opus 4.6 相同（输入 $5/M tokens，输出 $25/M tokens） 可用渠道：Claude 全系产品、API、Amazon Bedrock、Google Vertex AI、Microsoft Foundry 📈 主要技术升级 1️⃣ 编程能力大幅提升 在 Anthropic 内部 93 项编码基准测试中： 指标 Opus 4.6 Opus 4.7 提升 综合解决率 58% 70% +12% 复杂任务 部分失败 解决 4 个新任务 首次突破 工具错误率 基准 减少 1/3 大幅提升 执行连续性 易中断 贯穿工具故障 显著改善 用户反馈（来自早期测试）： Devin：长时间自主工作数小时，攻克此前无法解决的难题 Cursor：CursorBench 从 58% → 70% Factory Droids：任务成功率提升 10-15%，更少工具错误 CodeRabbit：代码审查召回率提升 10%+ 2️⃣ 多模态视觉增强 参数 Opus 4.6 Opus 4.7 最大长边分辨率 ~800px 2,576px（约 3.75MP） 提升倍数 1× 3×+ 应用场景： ...

🧠 记忆分层架构（原生 3 层 + 我扩展的 2 层） 层级 存储形式 生命周期 用途 访问范围 0️⃣ 会话上下文 当前对话历史（数组） 单次会话 实时理解、即时决策 当前 session 1️⃣ 每日日志 memory/YYYY‑MM‑DD.md 永久（文件） 原始事件记录、原始决策、待办 当前 agent（main session） 2️⃣ 长期记忆 MEMORY.md 永久（文件） 精炼知识、经验总结、偏好、教训 仅 main session（安全隔离） 3️⃣ 结构化知识 Ontology 知识图谱（可选技能） 永久（图谱文件） 实体关系、项目依赖、跨技能状态共享 安装了 ontology 技能时 4️⃣ 跨会话索引 已索引的会话记录（内部存储） 永久（索引） 搜索历史对话、跨会话回忆 通过 memory_search 工具 5️⃣ 外部补充 Compiled‑wiki 补充资料（可注册） 永久（外部） 额外文档、知识库 memory_search corpus=wiki 📂 各层详情 0️⃣ 会话上下文（Session Context） 内容：本次对话的最近数十条消息。 特点：临时性，session 结束后自动消失（除非显式持久化）。 用途：维持对话连贯、处理指代。 1️⃣ 每日日志（每日日志） 路径：<workspace>/memory/YYYY‑MM‑DD.md 写入时机： 重要事件发生后（如完成任务、发布博客） Heartbeat 检查时归档临时信息 示例： ## 2026‑04‑29 - 解读 browser-use 仓库 - 创建 DeepSeek V4 博客文章 - 更新 TOOLS.md（新增 browser-use 技能笔记） 安全：仅在 main session（直接对话）自动加载，群聊、共享环境不读取。 2️⃣ 长期记忆（MEMORY.md） 路径：<workspace>/MEMORY.md 本质：策划后的精华记忆，相当于人类的长期记忆。 存放： 用户偏好（如“主人喜欢简洁技术总结”） 重要决策（如“默认模型改为 GLM‑4.7”） 经验教训（如“避免在群聊中加载 MEMORY.md”） 项目上下文（如“blog‑demo 使用 Hugo + PaperMod”） 维护：Heartbeat 定期回顾最近的每日日志，提炼有价值信息写入。 3️⃣ 结构化知识（Ontology） 技能：ontology（如果已安装） 模型：实体（Person、Project、Task、Event、Document）+ 关系（link、depends_on 等） 好处：跨技能共享状态、约束检查、依赖可视化，适合复杂业务工作流。 4️⃣ 跨会话索引（Session Transcripts） 机制：OpenClaw 为每个会话生成 sessions/YYYY‑MM‑DD‑<slug>.md 并自动建立向量+BM25 混合索引。 检索：memory_search(query, corpus="all") 自动搜索这些索引。 检索原理： 向量搜索（70% 权重）捕捉语义相似度 BM25（30% 权重）保证精确关键词匹配 每块约 400 token，80 token 重叠，SHA‑256 去重 5️⃣ 外部补充（Compiled‑wiki） 用途：接入公司内部 Wiki、产品手册、行业文档等外部知识库。 访问：同样通过 memory_search corpus="wiki" 检索。 🔍 原生检索机制 向量 + BM25 融合（70%/30%） 块分割：400 token 块 + 80 token 重叠，防止上下文丢失 去重：块 SHA‑256 哈希，已有向量直接命中缓存 压缩触发：当会话快达到上下文上限时，系统会让模型在压缩前把关键信息写入 memory/*.md 或 MEMORY.md（即所谓的 “Dreaming”） 📦 实际操作示例 # 查看今天的日志 cat $(date +%Y-%m-%d).md # 向长期记忆写入关键结论（示例） cat >> MEMORY.md <<EOF - 结论：使用向量+BM25 的混合检索可以兼顾概念关联和精确匹配。 EOF # 用 ontology 记录项目关系 ontology create entity Project name="blog-demo" ontology create relationship link source=Project target=Document name="deepseek-v4.md" 🔐 记忆安全与隔离（简要回顾） 文件系统权限：700 目录、600 文件，仅当前 agent 可读写。 会话层隔离：MEMORY.md 只在 主私人会话 加载，避免在群聊泄露。 审计日志：每次写入都会记录在 memory/heartbeat-state.json，可追溯。 子代理 sandbox：默认只读工作区，写入必须显式声明。 可选加密：若有合规需求，可对 MEMORY.md 进行 AES‑256‑GCM 加密。 🎯 小结 OpenClaw 的记忆分层把 即时日志、长期精华、结构化实体、跨会话索引 和 外部 Wiki 五层有机结合，兼顾 可检索性、安全性 与 可维护性。 通过 混合向量+BM25 检索、块去重 与 Dreaming 机制，保证重要信息不被上下文压缩遗失。 正确使用 memory_search、memory_get、ontology 等工具，可以让企业 AI 助手在 千余次会话 后仍保持对关键业务的清晰记忆。 #openclaw #龙虾 #memory ...

🚀 GLM Coding Plan 速来拼好模，智谱 GLM Coding 超值订阅，邀你一起薅羊毛！Claude Code、Cline 等 20+ 大编程工具无缝支持，“码力”全开，越拼越爽！立即开拼，享限时惊喜价！ 链接： https://www.bigmodel.cn/glm-coding?ic=RTWWS8HOD6 🔥 火山方舟特惠编程 Plan 方舟 Coding Plan 支持 Doubao、GLM、DeepSeek、Kimi 等模型，工具不限，现在订阅 折上 9 折，低至 8.9 元，订阅越多越划算！ 立即订阅： https://volcengine.com/L/vd1xvW2KKgg/ 邀请码：2DSAD6JL ☁️ 轻量云主机长期优惠 RackNerd 只要 80 元（3 TB 流量、1 vCPU、50 GB 硬盘） 购买地址： https://my.racknerd.com/aff.php?aff=14942 CloudCone 超低价轻量云主机 购买地址： https://app.cloudcone.com/?ref=12332 📢 腾讯云资源限时福利 有云服务器、CDN、对象存储、网络防护等需求的朋友，欢迎联系下方腾讯云官方销售 👇 ✅ 内部专属折扣，价格更优 ✅ 量大可谈，支持定制方案 ✅ 技术咨询与售后无忧 让 AI 编程更高效，让云资源更划算，一键打开技术生产力的全新可能！

发布时间：2026‑04‑24 模型名：deepseek‑v4‑pro / deepseek‑v4‑flash 上下文：1 M token（百万级） 核心技术：混合注意力、多维压缩、流形约束超连接、Muon优化器 1️⃣ 一览 版本 参数量 激活量 目标 亮点 V4‑Pro 1.6 T 49 B 最高端开源模型 V4‑Flash 284 B 13 B 极致效率/低成本 备注：两版均支持 1 M token 上下文，思考模式 (reasoning‑effort) 可调高/把握成本。 2️⃣ 技术回顾 2.1 混合注意力机制（CSA + HCA） CSA：在 KV 维度进行 4 : 1 压缩，结合 DSA 稀疏注意力，利用 Lightning‑Indexer 仅保留 top‑1024 KV 项。 HCA：压缩率 128 : 1，全部 KV 参与计算，滑动窗口‐512 tokens 跨层捕捉全局依赖。 优势：相比前代仅 27 % 的算力、10 % 的 KV 缓存，显存与训练成本大幅下降。 2.2 流形约束超连接（mHC） 采用双随机矩形流形（Birkhoff‑Polytope）约束残差映射，确保谱范数 ≤ 1，信息在深层网络不发散，训练稳定性上升 6.7 % 成本。 2.3 Muon 优化器 对梯度动量进行 Newton‑Schulz 正交化，10 次混合迭代实现快速收敛。 结合 Anticipatory‑Routing 与 SwiGLU‑Clamping，进一步提升训练速度与模型收敛稳定性。 3️⃣ 性能表现 指标 V3‑2 V4‑Pro V4‑Flash Agent‑Coding 开源前列 最高 接近 Pro 世界知识 较差 仅微距差距 次佳 推理速度 1.43× 3.80× 4.14× 1M KV 缓存 49 B 6.2 B 5.5 B 结论：V4‑Pro 以与 Gemini‑Pro‑3.1 并驾齐驱的性能，处理复杂 Agent 任务如代码生成、文档翻译等表现尤为出色；V4‑Flash 则以 13 B 激活实现极低成本、最快速度的 1 M‑上下文使用场景。 ...