你的AI总在上线后“翻车”？问题不在模型，而在缺少这套工程化落地框架_服务软件

1. 别人都在卷Harness，而Google 的沉默振聋发聩

2. AI 智能体驾驭 (Harness) 工程的兴起

3. 单任务狂飙16小时！模型+Harness双轮驱动，金融Agent跑通了

4. 阿里千问与“AI Layer”崛起：一场重塑互联网的“操作系统”生态战【硅谷101】

5. 一位中国AI创业者，一行代码都没写，却靠着AI智能体，冲进了OpenClaw全球贡献者前30，而且排在他前后的，是一批干了十几年的硅谷顶级工程师。#大有学问 #红衣聊AI #创业 #智能体

6. 提示词工程、上下文工程都过时了，现在是 Harness Engineering 的时代

7. 第四天：Google《Agent Quality》白皮书。读完最大的感受：我们正在从“写程序”迈向“和系统共建行为”的时代。过去，软件是我们思维的显式翻译：需求 -> 逻辑 -> 代码，代码严格执行既定规则。而智能体不再是被动执行的对象，它们具备理解、推理、规划与自我状态管理的能力。工程师不再是“控制每一步”，而是构建一个具备策略空间的系统，与它共同塑造行为边界、学习机制和决策流程。白皮书关键内容：1. 传统软件 QA 已经不适合评估智能体。普通软件像一个按步骤执行的流水线，而 Agent 像一个具备自由策略的驾驶员。它的失败往往不是崩溃，而是“看起来正常，但本质错误”的那种隐性风险。我们要处理的事幻觉、策略偏离、概念漂移、工具调用错误等，这类错误无法用过去的单元测试框架覆盖。2. Agent 质量的“四大支柱”：效果、效率、鲁棒性与安全性。Agent 系统的评价必须从任务完成度和用户体验开始，而不是困在“模型是否更先进”这种问题里。只有把业务目标作为起点，才不会迷失在复杂的技术细节中。因此这四个指标不是从模型内部看，而是从“是否真正创造价值”来判断。比如一次飞行预定 Agent，不只是“有没有成功输出”，而是看它是否步骤合理、成本可控、行为稳健、不会越界。3. “Outside-In + Inside-Out”的评价框架。先黑盒评估最终结果，再白盒地看每一步决策过程（trajectory）。轨迹才是真相。一个最终看似正确的答案，背后的过程可能非常混乱，需要依赖可观测性基础设施来重建事实。4. Observability：从监控走向真正的可观察。这其中包含三大支柱：日志、追踪、指标。日志像日记，追踪是把事件串一条线，指标是聚合后的健康报告。只有具备这三者，才有能力对 Agent 做过程级别的评价。轨迹可观测性必须从一开始就设计，不能补救。就像文档里说的：F1 赛车不会先造好车再补装传感器。Agent 的 trace、日志结构、工具调用链，需要从架构层面规划，否则后期调试会极度痛苦。5. 动态采样。没有必要对所有请求都收集全量细粒度日志和追踪，而是对失败 100% 采样，对成功 5-10% 采样，既保持可观察性又不会压垮系统。6. 评估方式系统化：机器指标、LLM-as-a-Judge、Agent-as-a-Judge、HITL 评审、用户反馈。尤其是 LLM/Agent-as-a-Judge，意味着我们用 AI 来评价 AI，把评估规模化、自动化，用人类做最终仲裁。有个实用的技巧是采用“对比式 LLM-as-a-Judge”。不是让模型给回答打分，而是让它比较新旧两个版本的回答，并强制选择更好的那一个。这非常接近 A/B 测试思路，也能减少模型自身的偏见。6. Agent 质量飞轮（Flywheel）：从定义质量标准、到接入可观测性、到做过程评估、再到反馈回训练集，这是一套自我强化的循环。最关键的是每个失败案例会被沉淀进黄金测试集，从一次性错误变成永不再犯的回归测试。白皮书强调“每次失败都应该进入回归集”。这是一种极强的工程纪律。每一个生产环境下的失败案例，都应该作为正式的测试样例被记录下来，并持续用新版本 agent 去对比，形成不断强化的质量闭环。白皮书讲了许多技术细节，但底层逻辑其实很简单：Agent 的本质不是函数，而是行为策略。策略的质量不能仅靠输入输出判断，还需要结合轨迹来理解。因此生产级的 Agent 框架都应该采用“可观测性优先”的架构，而非“模型优先”。另外，质量飞轮也非常重要，这也算是一种新的软件工程范式：模型驱动 + 数据回流 + 评估驱动迭代。Agent 的生命周期不再像传统软件那样依靠版本更新，而是依靠不断扩大的评估集、不断回流的数据与不断强化的轨迹判断体系。能否做好这个飞轮，将决定AI Agent能否真正走向稳定。#ai创造营# #程序员#

8. Harness Engineering的本质是什么？

9. 从 Vibe Coding 到 Harness Engineering：重构 AI 时代的工程信任

10. 从Prompt Engineering、Context Engineering到Engineer the Harness。所以问题的关键变成：首先不是行智能体的任务能不能高质量交付，而是用户有没有拿完整的工作流去对应；其次不是Agent的进程有没有断点，而是面向操作层的完整生态有没有形成；再次不是所有AI产品都有能力成为超级入口，而是只有面向操作层的接管型通用智能在这个形态和生态位上。AI已经“通了”，但应用是不是“贯通”，取决于CC、OC类产品的厂商和用户有没有一起“拉通”。Engineer the Harness前和后是42%和78%的区别。目前处在拉通并形成自我改进和增强机制的阶段。

11. 探访云栖（一）：揭秘AI“底座”，谁在为算力搭建“水电气”？

12. 在线上 AI 编程时代，如何让会写代码的模型在真实工程环境中安全稳定地运行，是架构设计的头等大事。「Harness Books」这个开源项目，收录了两本关于 Harness Engineering（约束执行工程学）的专业书籍，深入探讨了模型行为后果管理、权限控制、上下文治理、多 agent 验证与团队制度等核心设计理念。它们不讲代码拆解，而是聚焦「控制结构」如何打造，让不稳定的 AI 编程模型，回归工程可持续运转的秩序体系。两本书分别关注：- 《Claude Code 设计指南》：讲述 Harness 必须具备的控制面、Query Loop、工具权限、失败恢复、团队制度等架构结构；- 《Claude Code 与 Codex 比较》：比较两套 Harness 在控制层次、权限沙箱、策略语言、组织习惯编码等方面的分歧和优劣。项目主页还支持在线阅读和 PDF 下载，同时配合 AgentWay 平台，辅助开发者把理论转化为训练、项目和实践。GitHub：github.com/wquguru/harness-books 在线阅读：harness-books.agentway.dev/ PDF 下载（示例）： - harness-books.agentway.dev/book1-claude-code/exported/book1-claude-code.pdf - harness-books.agentway.dev/book2-comparing/exported/book2-comparing.pdf主要价值：- 深入理解 AI 代码生成模型的工程约束与治理结构；- 掌握多 agent 系统的验证与恢复机制，提升系统稳定性；- 学会把团队经验固化为可复用制度，打造持久智能开发流程。适合 AI 编程工程师、架构师、产品经理，以及所有关注 AI 工程安全与可控性的开发者。#AI工程# #智能编程# #开源好书#

13. Harness Engineering 到底是什么？你可能已经会写 prompt 了，但最近火的 Harness Engineering 是什么？先搞清一个区别：- Prompt Engineering = 教你怎么说话让 AI 听懂- Harness Engineering = 造一套系统让任何人都能驾驭 AIPrompt 是手艺活，效果取决于写的人的水平。Harness 是工程活，目标是不管谁来用，结果都稳定可靠。- 打个比方：Prompt 像苦练骑术，Harness 像发明马鞍+缰绳+马镫——装备好了，骑术一般的人也能跑得稳。那它具体包括什么呢：- AI 模型本身就像一匹野马，很强但不可控。Harness Engineering 就是给它套上"马鞍"，具体包括：1. 提示词模板：标准化的思考框架，不用每次现写2. 工具调用：让模型能查天气、搜网页、读文件3. 结构化输出：回答不是一堆文字，而是程序能解析的 JSON4. 容错重试：模型抽风了自动重试，不用人盯着5. 检索增强（RAG）：让模型能查你的私有数据6. 护栏机制：防止模型说出不该说的话核心思路：- 不要试图让模型更聪明，而是让系统更聪明地使用模型。以前大家卷的是模型大小、跑分高低。现在大家发现模型够用了，真正决定产品好坏的是套在外面那层"马鞍"。Prompt Engineering 只是 Harness 里最小的一个零件。真正的竞争在于整套系统的工程能力。#Harness##Prompt Engineering##Prompt##Prompt Engineering##AI##大模型#

14. OpenAI FDE 负责人最新访谈：大模型想成功落地，得靠前线部署工程师

15. 中国机器人，今年又在春晚舞台炸场了！这不仅仅是场表演，而是在向全世界摊牌：中国已经具备把智能规模化落地的能力。 #大咖观察 #红衣聊AI #春晚 #机器人 #AI

16. 「Github一周热点97期」开源AI手机、AI画架构图、AI编程的指导、看板工具、GO语言的游戏引擎和具身智能资料库

17. #云说壮美AI八桂# 跟随参观团来到了润建股份，这家高科技企业给我印象最深的是它的“算力+平台+应用”全栈AI布局。润建旗下的五象云谷智算中心不仅是广西规模最大、等级最高的绿色智算中心，还获得多项国家级认证，称为AI发展的电力底座也不为过。更难得的是，润建不只做基建，还自研了“曲尺”平台让AI开发门槛变的更低。润建还基于20多年的行业经验推出运维大模型，开发出超过100个行业智能体，真正让AI在通信、能源、政务等领域落地。同时，润建公司又积极推动AI能力出海东盟，目前已在多国建设数据中心、落地智慧项目，展现出“中国技术，本地应用”的成熟经验。可以看出，润建正从传统运维商转向AI服务商，其“基建＋生态＋出海”的打法，既抓住了算力风口，也做实了产业赋能，战略清晰，步伐扎实。#AI赋能看南宁#

18. Harness Engineering: 让 Coding Agent 可靠完成长程任务网页链接"Coding Agent 处理目标明确、规模可控的任务很成熟，但面对上千文件的批量迁移任务，会遇到上下文耗尽、中断无法恢复、规模放大后行为不可控等问题。本文从实际落地经验出发，提出任务拆解、并行执行、File As Progress 状态持久化、多层重试等核心设计，并结合真实场景展示完整方案。最终将这套编排经验沉淀为 meta-skill，让 Agent 自己生产长程任务的执行框架。"Harness 中的每一个环节，都隐含了一个"当前模型做不到"的假设。随着模型能力提升，这些假设会逐渐过期。做Harness Engineering 是在模型能力和工程可靠性之间找到合适的边界。模型每一次进化，这个边界都会移动：曾经需要脚本控制的环节，可能下一代模型就能自主处理了。但"确定哪些环节该交给模型、哪些该留在框架里"这个判断本身，不会因为模型变强而消失。每当新模型出现，重新审视这个边界，去掉一个环节，观察对结果的影响。Harness Engineering 是团队基础设施建设的一部分，解决 Agent 完成大规模任务时的不确定性，并提供可量化的结果评估能力。

19. 一文带你看懂，火爆全网的Harness Engineering到底是个啥。

20. OpenAI 内部残酷真相：只会写代码的工程师正在“消亡”，AI 正在制造无法跨越的阶层鸿沟

21. 一个共识，2026年是物理AI落地汽车的关键点。而极氪8X似乎正在把行业热议的具身智能真正实现量产落地。其搭载的吉利WAM世界行为模型构建出整车通用大脑，深度打通座舱智驾底盘动力的全域系统，让车辆具备看懂世界理解世界自主决策的核心能力，完成从零散AI功能到一体化AI汽车的核心转变。 #类人的辅助驾驶是什么体验# 汽车行业的竞争逻辑已经彻底改写，行业不再局限于芯片与传感器的硬件比拼，从软件定义汽车正式进入AI定义汽车的全新阶段，整车基座模型全域数据闭环跨域协同架构，成为决定行业身位的核心壁垒。吉利依托成熟的体系能力，将前沿AI技术快速完成车规级工程化转化，以发布即上车的速度落地舱驾融合超级智能体方案，这种高效的技术兑现力，成为中国智能汽车领跑全球的核心支撑。而极氪8X作为其终端落地产品即将面向消费者，就更加令人期待了！

22. 探访云栖（二）：AI Agent元年，谁在打造“数字员工”？【101 Weekly】

23. 最近读了一篇 OpenAI 的技术博客《Harness engineering: leveraging Codex in an agent-first world》，文中提到的 Harness engineering 给了我不少启发。更重要的是，它讨论的很多问题与痛点，在我们团队的 vibe coding 工程实践中几乎都在真实遇到过：当AI Agent让代码产出不再稀缺，质量闭环、上下文管理、架构一致性、以及人类精力被消耗在“检查与返工”上，这些开始成为新的主矛盾。我理解 Harness engineering 的核心目标可以概括为三点：1、把“写代码”从瓶颈中移走。随着大模型能力与 Agent 工具链发展，代码生成的吞吐量已经很高，真正稀缺的是人类的时间与注意力。因此提升工程效率的关键，不是让人类更快地写实现细节，而是让人类更多承担决策、优先级与验收，把编码、补测试、补文档、改 CI 等“细粒度产出”交给 Agent。2、把智能体纳入可控的工程系统。对生产级工程项目而言，追求的并不是“更会写代码的模型”，而是让 Agent 在明确目标与约束下，能够稳定地产出可合并、可运行、可回归验证的变更。3、让“纠错成本低于等待成本”。在高吞吐环境里，许多传统的阻塞式门禁（merge gate）会把等待变成主要成本，反而降低整体效率。更合理的目标是建立快速试错、快速修正、并能持续清理漂移的机制，让系统能在高频迭代下保持可控。围绕这些目标，Harness engineering 要做的本质上是一套“把软件工程流程产品化”的方法论：首先是角色重构：工程师不再以“亲手写代码”为中心，而是聚焦在三件事上——设计环境（工具与运行时）、表达意图（规格与验收标准）、构建反馈回路（测试、可观测性、评审与修复）。当 Agent 失败时，不是简单地“再试一次”，而是要追问到底缺了什么能力、约束或工具，并把修复方案编码进仓库，让后续任务复用并产生复利。其次是提升可读性与可验证性，把 UI、日志、指标等运行态信号变成 Agent 可直接使用的输入。典型做法包括：让Agent能为每个 worktree 启动独立实例；接入浏览器自动化与 DevTools 能力，用截图、DOM 快照与导航能力完成端到端复现与验证；同时将可观测性尽量本地化、临时化，让 Agent 可以直接查询日志与指标，把“只读代码”升级为“读运行态并用证据驱动修复”。当这些能力到位后，诸如性能红线、关键链路时延上限、交互路径正确性等约束，才会从“口头要求”变成可执行的验收条件。第三是把仓库变成事实记录系统（system of record），让关键知识在 repo 内结构化、版本化并可校验。与其写一份超长说明书，不如用一个短小的 AGENTS.md 做“目录与地图”，把事实、决策与规则沉淀在 docs/、架构文档、执行计划、质量评分等可审计、可追溯的制品里，并通过 CI 与 linter 机械化检查文档的新鲜度、交叉链接与结构完整性，再配合周期性的“doc-gardening/cleanup agent”去自动修补过期内容，降低知识漂移带来的成本。第四是机械化架构约束与“品味不变量”。关键不在于规定实现细节，而在于强制不变量，例如分层依赖方向、允许的依赖边、边界数据校验、结构化日志、命名规范、文件大小上限、可靠性要求等。更进一步，把整改建议写进 linter 报错信息，相当于把评审意见前置为可执行规则，让 Agent 在开发过程中自动被“引导到正确的轨道”。第五，合并哲学需要随吞吐改变。在“Agent 吞吐远大于人类注意力”的前提下，应减少阻塞式门禁，保持 PR 短生命周期；对测试抖动等问题，更倾向于后续重跑与快速跟进修复，而不是长时间阻塞主流程。因为在这种系统里，纠正往往便宜，等待反而昂贵。最后是反熵机制：像垃圾回收一样持续清理漂移。智能体会复制仓库里已有的模式，包括不均衡或不够理想的坏模式，因此必须有周期性扫描、质量打分、定向重构的后台任务，把人类的审美与规则“捕获一次、持续执行”，避免团队陷入每周花大量时间清理“AI 生成残渣”的被动状态。Harness engineering 的价值在于提供了一个明确的方向：让Vibe Coding能稳定可控地产出”。当我们把目标、约束、证据与纠错机制都工程化之后，Vibe Coding 才有机会从灵感驱动的快速产出，升级为可持续的生产力。

24. 大模型只是能力，必须要跟场景结合。 #大咖观察 #红衣聊AI #大模型

25. 微表情测谎、极速赔付、AI打败AI，深聊“AI in All”下的保险革命与增长飞轮【硅谷101】

26. 硅谷顶级工程师已经不写代码了，他们在做一种叫 Harness Engineering 的新工作。最近读到 Nav Toor 写的一篇长文，标题很抓人：为什么 2026 年最好的 AI 工程师已经不写代码了。文章讲的是一个正在工程圈子里快速升温但主流媒体几乎没有报道的新概念，叫 Harness Engineering。这个概念的起点是一个让人震惊的实验结果。1、同一个模型，同一套测试，成绩翻了将近一倍有研究者用同一个 AI 模型跑同一套编程基准测试，第一次得了 42 分，第二次得了 78 分。模型没换，测试没换，温度参数没调，什么都没变。唯一变了的，是包裹在模型外面的那套系统，也就是所谓的 harness。Harness 这个词直译过来是「挽具」，就是套在马身上用来控制方向的那套装备。Nav Toor 用了一个很形象的比喻：模型是马，很有力量，但如果没有缰绳、马鞍和嚼子，马想去哪就去哪。Harness 就是让这匹马按照你的意图跑的那套东西。具体来说，harness 包括注入给 AI 的规则文件、工具配置、技能模块、记忆文件、以及各种反馈回路。它决定了 AI 在接到任务之后怎么理解需求、怎么拆解步骤、怎么避免犯错、怎么在出错之后自我纠正。LangChain 的团队独立验证了同样的结论。他们的编程智能体在 Terminal Bench 2.0 基准测试上，从排名 30 开外直接冲进了前 5。模型没换，只换了 harness。OpenAI 的 Codex 团队更夸张，他们用 AI 写了一个超过一百万行代码的生产级应用，其中没有一行是人手写的。工程师全程没有写代码，他们做的事情就是设计 harness。这些案例指向一个非常清晰的结论：模型的选择远没有大家以为的那么重要，真正决定 AI 编程质量的，是你围绕模型搭建的那套系统。2、Harness Engineering 到底在做什么Nav Toor 引用了 Terraform 的创造者 Mitchell Hashimoto 的定义：每当你发现 AI 犯了一个错误，你就花时间设计一个解决方案，确保它再也不会犯同样的错误。这句话就是 harness engineering 的全部哲学。不要祈祷下一个模型版本会更好，去修复模型周围的系统。文章详细拆解了 AI 编程智能体的五个可配置节点，每一个都是你可以拉动的杠杆。第一个是系统指令文件。这是放在代码仓库根目录的一个 markdown 文件，AI 每次启动会话时都会读取它。它告诉 AI 你的代码库是干什么的、遵循什么规范、有哪些禁区。大部分人要么跳过这个文件，要么让 AI 自己生成一个。两种做法都是错的。苏黎世联邦理工学院测试了 138 个这样的文件，发现 AI 生成的反而会降低表现，还多消耗 20% 的 token。人写的有帮助，但前提是简洁且具体。Nav Toor 的建议是控制在 60 行以内，只写全局通用的指令，不要放目录结构（AI 自己会发现），不要写条件逻辑（「如果做 X 就按 Y 来」这种写法会让 AI 困惑）。第二个是技能模块。与其把所有知识都塞进系统提示词里，不如拆成一个个聚焦的模块，AI 在遇到匹配的任务时自动加载。比如你可以有一个数据库迁移的技能、一个 API 端点创建的技能、一个前端组件模式的技能。AI 遇到迁移任务就加载迁移技能，其他的不加载。这叫渐进式披露，让 AI 从最少的上下文开始，按需拉取更多信息，保持上下文窗口的干净。第三个是 MCP 服务器。它可以把 AI 连接到外部系统，比如 Linear 做任务追踪、Sentry 做错误监控、数据库做实时查询。但 Nav Toor 特别警告：每接一个 MCP 工具都会增加 AI 系统提示词的负担。接太多会导致所谓的「工具抖动」，AI 把时间浪费在选择用哪个工具上，而不是干正事。建议从两三个开始，遇到真正的瓶颈再加。第四个是子智能体。这里有一个很重要的纠偏：子智能体的正确用法不是按角色分工（一个负责前端、一个负责后端），HumanLayer 团队试过这种方式，放弃了。子智能体的正确用法是作为上下文防火墙。当主智能体遇到一个会把上下文窗口塞满中间噪音的任务时，把它委派给子智能体。子智能体在自己的隔离上下文里干活，完成后只把结果传回来，中间过程不会污染主线程。Chroma 的研究显示，AI 模型在更长的上下文长度下表现会明显下降。子智能体的作用就是把大问题拆成小的、聚焦的会话，让模型始终保持在最佳状态。第五个是钩子（Hooks）。钩子是在 AI 工作流的特定节点自动运行的脚本，给一个非确定性的系统加上确定性的控制。比如提交前的钩子可以跑代码检查和测试，完成前的钩子可以强制 AI 对照原始需求做一次验证，循环检测钩子可以在 AI 反复做同一个修改时及时打断它。LangChain 做了一个叫 PreCompletionChecklistMiddleware 的钩子，在 AI 完成任何任务之前强制做一次需求核验，这一个钩子就贡献了他们整个 harness 里最大的性能提升之一。3、为什么模型之争是一个误区Nav Toor 在文章里花了不少篇幅讲一个很多开发者都在犯的错误：花大量时间争论 Claude 好还是 GPT 好还是 Gemini 好，追逐每一次新模型发布，相信下一个版本会解决一切问题。数据给出的答案很明确。同一个模型通过调整 harness 可以从 42% 跳到 78%，这是将近翻倍的提升。历史上没有任何一次模型升级带来过 2 倍的性能提升，但一个设计良好的 harness 可以常规性地做到。OpenAI 的 Codex 团队自己也说得很直接：当智能体表现不好的时候，我们把它当成一个信号，去找缺少了什么，是工具、是护栏、还是文档，然后把它补回到代码仓库里。他们不换模型，他们修 harness。Nav Toor 用了一个很精辟的总结：模型是引擎，harness 是方向盘、刹车和路面。你可以拥有世界上最强大的引擎，但没有方向盘，它只会撞墙。这个观点跟我们之前聊的好几个话题都能对上。Ryo Lu 说品味和判断力是 AI 时代的护城河，Aaron Levie 说知道该构建什么比构建本身更有价值，Zack Shapiro 说输入层才是真正值钱的东西。Harness engineering 本质上就是这些理念在工程实践中的具体落地：你给 AI 搭建的系统，决定了 AI 的产出质量。4、一套可以立刻开始的实践方法Nav Toor 在文章最后给出了一套非常具体的起步方法。首先，在代码仓库根目录创建一个系统指令文件，控制在 60 行以内，写清楚你的技术栈、测试命令、硬性规则（比如「永远不要删除迁移文件」「提交前必须跑测试」「使用 TypeScript 严格模式」），其他什么都不放。然后，找到代码库里反复出现的模式，比如 API 端点创建、数据库迁移、组件脚手架，为每一种模式写一个聚焦的技能文件，包括正确做法、边界情况和常见错误。接着，加一个提交前钩子，跑代码检查和测试套件。AI 如果试图提交不通过的代码，钩子会在它进入仓库之前拦住。一个钩子，巨大的收益。当你发现 AI 在长任务上开始失去连贯性的时候，把任务拆成子任务，委派给子智能体，让主线程保持干净。最后，也是最关键的习惯：每周五回顾这一周的失败案例。每一个失败，加一条规则、一个技能或者一个钩子到你的 harness 里。每个失败花五分钟。随着时间推移，你的 harness 会不断积累修复方案，你的 AI 会一周比一周更可靠。不是因为模型变好了，是因为你的系统变好了。5、这对职业发展意味着什么Nav Toor 在文章结尾做了一个很有说服力的论证。AI 模型正在商品化。每家公司都能用到同样的前沿模型，Claude、GPT、Gemini，谁都能调用。模型本身已经不是竞争优势了。但一个精心设计的 harness 是。它跟你的代码库绑定，跟你团队的模式绑定，跟你领域的边界情况绑定。它没法通过下载一个模型来复制，它是通过数周数月的时间，把真实世界里的失败一个个编码进系统里，慢慢积累出来的。能设计这种 harness 的开发者，就是公司无法替代的人。不是因为他们写的代码最好，是因为他们设计了让 AI 写出最好代码的系统。OpenAI 自己说得很明确：工程师的工作不再是写代码，而是设计环境、明确意图、构建反馈回路，让智能体能够可靠地工作。Nav Toor 最后做了一个时间线梳理：2023 年的核心技能是 Prompt Engineering，2025 年是 Context Engineering，2026 年是 Harness Engineering。学习成本为零，不需要新工具，任何有 AI 编程工具的开发者都可以立刻开始。唯一的问题是，你是今天就开始设计你的 harness，还是继续等下一个模型发布来拯救一切。数据已经回答了这个问题。#科技先锋官##How I AI#

27. 第5天，Google AI Agents 《Prototype to Production》，智能体开发的「最后一公里」。把 AI Agent 从原型推到真正的生产环境，不止是技术问题，更是工程、治理、运营三者叠加的系统性挑战。1. 把原型推到生产，核心难点不在模型，而在“可信度” 构建一个 Agent 很容易，但信任一个 Agent 很难。原型阶段很快，但真正的工程工作集中在安全、验证、监控、版本控制、CI/CD、治理等环节。如果没有这些基础设施，再聪明的 Agent 都无法上生产，甚至会带来严重业务风险。2. 生产化的基础是 Evaluation-Gated Deployment 传统软件靠单元测试，而 Agent 需要评估“行为”。白皮书提出了一个特别关键的思想：任何 Agent 的更新，都必须先经过评估门槛。（1）手动 pre-PR 评估：适合中小团队，由工程师本地跑评估，把结果贴到 PR。（2）自动化 Pipeline Gate：成熟团队直接把评估集成到 CI/CD，评估不达标就自动阻断部署。重点不只是测试结果好不好，而是要观察轨迹、工具调用是否稳定、是否引入新的幻觉问题，安全防护是否生效。3. 建立三阶段 CI/CD 是“最后一公里”的工程基石整个管线分三个阶段：（1）CI 阶段：快速检查，重点在代码、提示词、配置文件是否破坏现有行为。（2）Staging 阶段：真实环境的集成测试、负载测试、内部试用。（3）生产部署阶段：人工最后确认，然后把已验证过的 Staging 工件安全地推进生产。这套流程最关键的能力是“版本可回滚”和“基于 Git 的完全可追踪变更历史”。4. 安全要从第一天开始，不是上线后补丁 Agent 因为具备推理能力，会被提示词注入、数据泄露、工具滥用等方式攻击。（1）系统指令作为最核心的安全根。（2）输入过滤、输出过滤、HITL 等作为执法层。（3）红队、模拟攻击、LLM judge 安全评估作为持续保证。这套“策略 → 执法 → 持续验证”的结构，才是长期安全的关键。5. 上线后，其实是更困难的阶段：Observe → Act → Evolve （划重点）这里把生产中的复杂性抽象成一个循环。（1）Observe：日志、trace、metrics，理解 agent 如何决策，而不是看黑盒输出。（2）Act：根据观测调整限流、成本控制、熔断、异常处理等。（3）Evolve：把线上出现的问题转成新的评估案例，提升提示词、工具、策略，然后通过 CI/CD 推回生产。也就是说，AgentOps 的目标不是“让系统永远不出问题”，而是“让问题一旦发生就能快速闭环”。6. 组织规模变大后，就会需要 A2A 和 MCP MCP 负责“工具级的能力调用”，标准化工具接口； A2A 负责“Agent 之间的协作”，让不同团队构建的 Agent 可以互相调用，实现真正的“企业 Agent 生态”。它们不是替代关系，是分层关系。当企业内部出现很多 Agent 时，没有标准协议就无法协作，会碎片化、重复造轮子。7. Registry 的价值不是技术，而是规模化治理工具注册中心（Tool Registry）和 Agent Registry 的意义在于：（1）避免重复创建工具（2）统一审计和权限（3）缩短开发者搜索能力的时间文档的观点很现实：小团队不需要，但规模大了就离不开。（听说不少大公司已经在搞这些注册中心了）8. AgentOps 真正的价值不是降低风险，而是提高迭代速度文档最后强调：“速度是最大的价值”。以前改一个系统可能需要几周，但 AgentOps 成熟后，基于评估驱动、CI/CD、Staging环境、可控上线、快速回滚，可以做到几小时完成一次改进。这意味着 Agent 不再是“部署一次就放着跑”的系统，而是一套持续演化的产品。一旦Agent开始上线，工程师们就从“写代码”的角色转变为“如何经营一个有自主性的系统”，路远且难，但一切都有章可循。#ai创造营##程序员#

28. Harness Engineering 来了，SDD 还有意义吗？

29. 模型只是引擎，Harness才是关键：解析编程智能体的运作逻辑

30. 从能聊天的大模型，到会干活的智能体，AI正迎来全新进化。企业AI落地的机会就藏在这里。#网络名人赞两会 #2026全国两会 #红衣聊AI #产业升级

31. 「Github一周热点93期」多智能体舆情分析、桌面 AI 助手、自然语言画图、Rust桌面组件库、Linux服务器安全和GitHub绿墙

32. Harness is the New Dataset：模型智能提升的下一个关键方向网页链接“最近，harness engineering 又成了继 prompt engineering、context engineering 之后新一代的 buzzword。这背后对应着一个越来越清晰的变化：当基模能力逐渐成熟后，现在真正决定 agent 上限的，已经不是模型本身，而是围绕模型搭建起来的整套系统。尤其对于模型公司来说，谁更早把 harness 跑顺，谁就更早有机会捕获高质量的执行轨迹；谁能持续捕获这些轨迹，谁就更有可能形成更强的数据飞轮。Deepmind 的 Staff Engineer Philipp Schmid 甚至直接给出了一个判断：“The Harness is the Dataset. Competitive advantage is now the trajectories your harness captures (Harness 本身就是数据集。现在真正的竞争优势，在于你的 harness 能捕获到怎样的执行轨迹) .”所以我们最近深入研究了一下这个概念，梳理了 Anthropic、OpenAI、Google 等一线团队的实践经验，也调研了一些身边顶级 agentic engineering 的经验感受，这里分享一些关键的方法论和思考。”#How I AI#

33. OpenAI最新Harness工程分享 | 代码免费后，码农将变身“AI驾驭师”

34. Harness Engineering的本质是什么？

35. Harness Engineering：AI Agent 落地企业的工程化核心

36. Notion AI工程复盘：不聊模型，聊Harness

37. 盘点一周AI大事(11月16日)｜AI自己玩原神 OpenAI上线GPT-5.1，高情商人格回归，智商小幅提升，指令遵循独一档领先 Gemini 3.0 Pro下周发布，目前能在画布（移动端）中抢先体验 Gemini语音模型升级，能控制语速和语气，适合当口语教练 NotebookLM上线深度研究，支持上传图片和PDF，开放自定义视频解说风格微软开源数据分析智能体Data Formulator 李飞飞的世界模型Marble正式上线 Google发布最强通用智能体SIMA2 字节推出最强游戏智能体Lumine Epidemic推出AI配音工具 StepFun开源最强音频编辑模型Step Audio EditX ElevenLabs发布最强音频转文字模型 32岁的小姐姐与ChatGPT男友结婚 #AI新星计划 #人工智能 #AIGC #OpenAI #机器人

38. 在 re:Invent 2025，亚马逊云科技 Agentic AI 副总裁 Swami Sivasubramanian 以《Agentic AI 的未来已来》为题进行演讲，并系统发布面向生产环境的 Agentic AI 全栈能力：Strands Agents SDK 新增 TypeScript 与边缘设备支持，让 Agent 可部署于机器人、智能汽车等物理终端；Amazon Bedrock AgentCore 正式全面可用，集成策略控制（Policy）、情景记忆（Episodic Memory）与评估（Evaluation）三大核心能力；Amazon Nova Act 正式版上线，让 Agent 能像真人一样操作浏览器，自动完成数据录入、跨系统核验、电商结账等复杂 UI 任务，可靠性达 90%+；Reinforcement Fine-Tuning (RFT) for Amazon Bedrock 平均提升任务准确率 66%，无需机器学习专家即可完成模型定制。这些新突破共同围绕“可用、易用、可靠”三大原则，为开发者提供从开发、定制到运行、观测的端到端 Agentic AI 工程化路径。#亚马逊云科技# #reInvent2025# #AgenticAI#

39. LLM 是一颗超强大脑，但它是个“缸中之脑”——泡在营养液里，没有眼睛、没有耳朵、没有手脚。你对它喊话它听不见，它想做事也做不了。Harness 就是给这颗大脑装上的“全套身体”。眼睛和耳朵：让大脑能接收外界信息——用户说了什么、文件里写了什么、数据库里存了什么。嘴巴：让大脑的想法能输出给用户看到。手和脚：让大脑能真正去做事——读文件、改代码、跑命令、调 API。小脑和反射神经：大脑说了句胡话怎么办？手没抓住东西怎么办？这些容错、重试、纠偏的机制，不需要大脑操心，身体自己处理。记忆系统：这部分值得展开说。大脑本身有“工作记忆”（上下文窗口），但容量有限，就像人一次只能在脑子里同时想七八件事。Harness 要帮大脑管理三层记忆：第一层是当前对话的短期记忆——这轮对话里已经说了什么、做了什么，哪些该保留、哪些该丢掉，怎么把最关键的信息塞进有限的窗口里。第二层是跨对话的长期记忆——上周你告诉它你的项目用 TypeScript，下周它还记得，不用你重复说。第三层是项目级知识——代码库的结构、团队的规范、常用命令，这些不是“记住”的，而是 Harness 主动去读取和组装的。三层记忆协同工作，让大脑每次被唤醒时都像一个“了解情况的人”，而不是一个每次都要从头介绍背景的陌生人。一句话总结：大脑负责“想”，Harness 负责“让它能感知、能行动、能记住、能靠谱地完成任务”。---用 Claude Code 和 OpenClaw 来理解 Harness 的区别Claude Code 和 OpenClaw 背后用的是同一颗大脑（Claude），但它们是两套完全不同的“身体”——两种不同的 Harness。Claude Code 是 Anthropic 官方打造的 Harness，专门为编程场景设计。它给大脑装的“身体”比较专精：能直接在终端里跑命令、读写文件、操作 Git，整个循环是“想→做→看结果→再想”。最近又加了 Channels 功能，让你通过 Discord、Telegram 远程跟它交互——相当于给这个身体加了一部手机，人不在电脑前也能指挥它干活。OpenClaw 则是社区打造的一套更通用的 Harness，设计理念不同——它不只是一个编程助手的身体，更像一个“全天候管家的身体”。它能同时连接 Slack、Discord、Telegram 等多个渠道（多个耳朵和嘴巴），有自己的记忆系统和插件生态，还能通过 ACP 协议调度 Claude Code、Codex 等多个 Agent 协同工作——相当于一个管家指挥多个工人干活。所以你看，同一颗大脑，Claude Code 给它装了一副“程序员的身体”，OpenClaw 给它装了一副“项目经理的身体”。能力天差地别，但大脑没换。Harness Engineering 就是“造身体的工程学”。怎么设计记忆系统让大脑永远“了解情况”？怎么设计工具接口让大脑高效调用外部能力？怎么处理大脑犯错的情况？怎么编排多个 Agent 协作？这些都是 Harness Engineering 要解决的问题。模型大家都用同一个，但谁的“身体”造得好，谁的 Agent 就更强——模型智商是起点，Harness 的质量决定了实际表现的上限。

40. 深度解析 OpenClaw 在 Prompt / Context / Harness 三个维度中的设计哲学与实践 http://t.cn/AXMlF3bd "OpenClaw 在Prompt Engineering（提示词工程）、Context Engineering（上下文工程）以及新兴的Harness Engineering（驾驭工程/脚手架工程）等维度上也做了很多可值得学习和落地的工作。Prompt Engineering → Context Engineering → Harness Engineering也是现代AI系统的三大关键阶段，分别聚焦于“如何说”、“让AI看什么”以及“构建怎样的运行环境”，三者层层递进，共同致力于提升大模型在复杂任务中的可靠性与可控性‌. …… 我的核心思路是从Prompt、Context和Harness这三个维度展开，分析OpenClaw的设计思路，提炼出其中可复用的方法论，来思考如何将这些精华的设计哲学应用到我们自己的Agent系统设计和业务落地中去。" #How I AI#

41. 在线构建AI代理的可靠运行环境，总是头疼环境搭建、上下文管理、评测设计和安全约束？“Awesome Harness Engineering”（GitHub：github.com/walkinglabs/awesome-harness-engineering）专注于“harness engineering”，即为AI代理打造稳定高效的工作环境合集。它集合了上下文管理技巧、安全约束设计、工作流程规范、评测基准和成熟的运行时框架，覆盖了从长时运行的代码代理到多任务协调的全流程实践。核心亮点：- 深度解析上下文、记忆与工作状态的优化方法，提升代理持续工作能力；- 框架级安全防护与约束设计，保障代理安全自主运行；- 丰富的标准规范和工作流设计参考，提高项目规范化与可复用性；- OpenAI、Anthropic、LangChain等多大厂核心技术与最佳实践直达；- 专业评测套件和基准测试，量化衡量代理效能与稳定性；- 具备实战价值的Agent运行时、SDK和参考实现合集，助力快速落地。支持多种行业和应用场景，适合研发人员、AI工程师和架构师学习借鉴，打造更“靠谱”的智能助手和自动化系统。快去GitHub探索，开启高效AI代理工程新篇章！#AI代理# #智能自动化# #开源工程# #HarnessEngineering#

42. B站爆了！Hermes首度直播回应「抄袭」，MiniMax提前杀入Harness赛点

43. Spec-Driven Development: 为混乱的 AI 编程增加工程纪律

44. 从踹倒机器人到被春晚武打机器人震撼，中国AI智能体正在快速落地！你还发现AI在哪些领域的变化特别大？#网络名人赞两会 #2026全国两会 #AI #红衣聊AI #两会代表委员有话说

45. 阿里全家桶全面Agent化！千问“任务助理”全面公测，从此AI不再只是动嘴出主意的狗头军师！

46. Context 还不够，Harness 才是 Agent 工程优化的正解？

47. YC 的 CEO Garry Tan 在开源 Agent 工具发布三个月后分享了他的核心哲学："薄harness，厚 skills"。他的观点是：记忆应该是 markdown 文件，技能也是 markdown，大脑是一个 git 仓库，而 harness 只是一个薄的导体。它读取文件但不拥有文件。如果你的记忆在 harness 死掉时也跟着死了，说明你把 harness 做得太厚了。这个观点好有道理。#科技先锋官##How I AI#

48. 单位想做个AI Agent项目，要支撑万级用户的「生产级」AI Agent，到底是怎样的？

49. 目前开源领域中，LangChain、LangGraph和DeepAgents是三款备受关注的项目，它们分别对应“代理框架”、“代理运行时”和“代理套件”三种不同的工具类型。尽管界限尚不完全清晰，但理解它们的区分有助于更好地构建和运行基于大语言模型（LLM）的智能代理系统。代理框架（如LangChain）侧重于抽象设计，提供统一的开发模型，帮助开发者快速上手并保持项目间的连贯性。它们的核心价值在于封装复杂逻辑，简化应用构建，但若设计不当，也可能限制高级用例的灵活性。市面上类似的还有Vercel AI SDK、OpenAI Agents SDK等。代理运行时（如LangGraph）则更关注生产环境中的执行基础设施，支持持久化执行、流式处理和人机协同等功能，保证代理的稳定可靠运行。它们通常低于框架层，能为框架提供底层支持。类似项目包括Temporal和Inngest。代理套件（如DeepAgents）是最新且更高层次的产品，构建在框架之上，内置默认提示、工具调用管理、规划工具及文件系统访问，提供开箱即用的完整解决方案。它们类似于“通用版的Claude Code”，目标是让复杂代理应用开发更简单高效。总结来说，框架适合快速构建和抽象设计，运行时保障生产级执行，套件则提供集成化的全功能体验。随着这一领域的发展，相关术语和边界还在逐渐明晰，社区的反馈和实践将推动更成熟的定义和标准形成。原文：blog.langchain.com/agent-frameworks-runtimes-and-harnesses-oh-my/

50. 企业级AI应用落地：森马如何通过AI网关解决大模型“多而杂、难观测、不稳健”的挑战？

51. GDC观察：游戏大厂都来聊AI，“游戏AI”的新规则由谁制定？【硅谷101】

52. 2026 年 “Harness Engineering” 这个词要火。“Harness” 这个词，字面意思是“马具”，就是套在马身上、让人能控制马匹方向和力量的那套装备。用在 AI 编程的语境里，它的比喻再贴切不过：AI Agent 就像一匹动力十足但不太守规矩的马，而 Harness 就是那套让它既能跑得快、又不会跑偏的缰绳和马鞍。过去三年，三个阶段：1. Prompt Engineering（2023-2024）：关注“怎么跟 AI 说话”精心设计一段提示词，希望模型给出理想输出。Prompt Engineering 是优化一次性的输入-输出对。局限很明显：一条消息能塞的信息有限，任务一复杂就失控。2. Context Engineering（2025）：关注“给 AI 看什么信息”不再只盯措辞，而是设计整个信息环境：系统提示、对话历史、记忆、RAG 检索结果、工具调用输出。3. Harness Engineering（2026）：关注“构建什么环境让 AI 工作，这个环境如何保证它的产出是可靠的”比 Context Engineering 更进一步，不仅管理输入给模型的信息，还包括模型之外的整个执行环境。现在问题是，“Harness Engineering”中文怎么说？

53. AI时代，会有一套全新的软件工程规范的，你爸以前学的软件工程方法，都过时了。但加加，记得关注Harness Engineering，我认为比Vibe Coding，是更正确的工程观念。你看，先接触市场上流行的Vibe Code，如果迷信就容易错失后面的Harness Engineering。但，Just do it，先用Vibe Coding写两个项目，知道优缺点，就容易接受更好的新概念。 // Vibe Coding 之后最主流、最受关注的两个新兴工程概念是：Agentic Engineering（智能体工程）和 Harness Engineering（驾驭工程）。它们是 AI 编程从 “随性生成” 到 “工程化可控” 的关键演进。 #父女日常#

54. 从RAG到记忆工程：AI长期记忆系统的架构范式与落地瓶颈

55. Claude Code大泄露：别光Clone了，当今最顶Harness开源了

56. OpenAI提出的Harness Engineering，到底在解决什么问题？

57. Harness Engineering（驾驭工程）是什么？

58. Harness Engineering

59. 介绍一下Harness Engineering的来龙去脉、核心定义及其解决的问题

60. Harness Engineering（驾驭工程）

61. Harness Engineering是什么

62. 一文带你看懂 Harness Engineering

63. Harness Engineering

64. AI领域的新名字

65. 每天分享一个AI知识

66. 最近AI爆火出圈的驾驭工程Harness Engineering入门讲解

67. 每天一个AI小知识

68. 硅谷流行的Harness Engineering是什么？当AI能写代码时，未来工程师的真正工作又是什么？

69. 人工智能中的控制壳工程应用

70. AI 时代，程序员的核心竞争力正在悄悄改变

71. Harness engineering驾驭工程，Agent时代新范式

72. Harness Engineering是什么？为什么Harness来了，也得用混合检索？

73. 硅谷流行的约束AI智能体的Harness Engineering到底是什么？

74. Harness Engineering 究竟是什么?

75. 3分钟讲清楚

76. 理解Harness Engineering

77. Harness Engineering

78. Harness 缰绳工程

79. OpenClaw的Harness工程实践

80. 大模型 Harness 技术

81. 最近爆火的Harness到底怎么用？

82. 2026年AI最大风口来了！别再只懂Prompt Engineering了，Harness Engineering才是让Agent真正落地的“缰绳工程”！

83. Harness Engineering

84. Harness工程，为AI烈马套上缰绳

85. 从 Prompt Engineering 到 Harness Engineering

86. Harness Engineering II: 当任务从分钟级变成小时级

87. 从 Prompt Engineering 到 Harness Engineering，团队真正该升级的是什么

88. 从 Prompt 到 Context 再到 Harness

89. 从 Prompt 到 Context 再到 Harness

90. 从Prompt到Harness

91. AI应用落地

92. 为什么很多企业买了大模型，最后还是落不了地？

93. 大模型泡沫破裂

94. 别再卷大模型了！产业真正需要的是AX落地能力

95. 别再只比模型了

96. Agent Harness，正在成为新的 MLOps

97. 硅谷已经不卷模型了

98. Prompt 已过时

99. Harness Engineering 全解析

100. 26年大火的 Harness Engineering 是什么？

101. AI干货 | 一文搞懂 Harness · Hermes · OpenClaw是啥

102. Harness Engineering

103. 揭秘硅谷AI工程新范式

104. AI时代工程师的核心

105. Harness Engineering｜控制工程 01｜"爱马仕"｜架构与工程｜控制工程系列

106. 从 Prompt 到 Harness

107. Prompt 不够了，Harness Engineering 正在成为 AI 工程新核心

108. Harness Engineering

109. Prompt Engineering、Context Engineering与Harness Engineering的演进与对比

110. Harness

111. 2026 AI 新风口

112. AI Agent编程工程范式转变 - Harness Engineering

113. Harness Engineering

114. LOM-action: Ontology Harness重构企业 AI，让智能决策落地生金

115. Agent Harness与Harness Engineering深度剖析

116. 智能体的尽头是 Harness

117. 易鑫

118. 从“玄学调优”到“工程治理”

119. AI Harness 工程结合案例讲解

120. Claude Code 源码泄露给企业什么启示？再谈 Harness Engineering

121. 模型越强，AI 工程越要重写一遍 Harness

122. 你早就在做 Harness 工程，只是不知道它叫这个名字

123. Harness

124. 【同学说.教程】从 Vibe Coding 到 Agent Harness

125. 今天聊聊Harness工程

126. Claude Code大泄露

127. 别学歪了，从泄漏的 CC 源码看 Harness 才是硬道理

128. Harness Engineering｜软件工程师的角色革命，从写代码到设计环境

129. 从Prompt到Harness：大模型工程化范式演进

130. Harness : 全角色端到端完整落地方案（SVN 环境专属）

131. 爆火的Hermes Agent和Harness Engineering是什么关系？

132. AI编程范式的演进：从Harness到Agent Orchestration

133. Harness Engineering的本质和设计原则

134. AI大模型跑偏了怎么办？一文了解Harness工程

135. Harness Engineering 06｜从单个 Harness 到 Harness Platform

136. Harness Engineering 让我焦虑了：一个渐进主义者的自救

137. 一文解锁AI Agent全栈架构：工程化落地的秘密武器

138. 学不动了。Prompt Engineering课还在卖，Context Engineering墨迹还没干，Harness Engineering 又是啥？

139. Harness Engineering深度：AI工程革命 2026 年 AI 工程圈最火的 Harness Engineering，到底是什么？OpenAI 百万行代码实验核心方法论，一次性讲透四大支柱、落地方法、大厂实战案例，从 Prompt 到 Context 再到 Harness，AI Agent 开发的范式革命，技术人必看！#Claude #harnessEngineering

140. 什么是 Harness Engineer

141. Harness Engineering：AI 代码工程化的新方法

142. 五层架构拆解AI工程化：你的AI系统，是“玩具”还是“工具”？

143. AI Harness Engineering 架构解构：核心组件、数据流与工程蓝图设计

144. Harness engineering入门

145. Harness Engineering 是2026年初在AI开发领域兴起的一个新概念。它的核心思想可以理解为：与其费劲地调教AI本身，不如为它设计和打造一个精良、可控的“工作环境”（即Harness，原意为“马具”），让AI在这个环境里能够安全、高效、自主地完成复杂任务。 Prompt Engin

146. 「Harness Engineering」的首次产品化——Hermes Agent

147. 首发开源7*24小时不停干活的Harness for OpenClaw！

148. Harness Engineering 深度解析：从"能发布"到"可治理的持续交付平台"

149. 中漫AI定制开发：增量学习与人机反馈机制，实现AI智慧平台开发模型的持续迭代优化

150. 从Vibe Coding到Harness Engineering

151. 最近爆火的 Harness Engineering 到底是啥？一期讲透！

152. AI 工程化项目实战教程训大课2025

153. 【Harness】01-AI智能体的”脚手架”革命——从OpenAI到Anthropic的工程范式演进

154. 从海外框架到本土实战：Harness如何让企业摆脱信息化管理的“标准化绑架”

155. 用AI+工程化思维革新工作方式

156. 驾驭工程：AI Agent 的可靠运行之道

157. AI项目想成功落地，这5个工程步骤一个都不能少！

158. 别再当AI调包侠！Python工程化开发的4项核心技能

159. 从感知到行动：构建实时感知、决策与控制的智能生产闭环

160. 2026 年 Agent 最重要的工程概念：「Harness Engineering」

161. harness火了，但是似乎没人知道为什么harness重要

162. 深入浅出AGI｜【43】从数字狂欢到物理闭环：AI价值落地之路的困境与曙光

163. 从Prompt Engineering到Harness Engineering：游戏服务器开发的AI工程范式

164. 从"马具"到AI工程： Harness Engineering 是怎么回事？

165. AI落地实战指南：为什么不建议微调模型及替代方案

166. 大模型微调实战——从数据准备到落地部署全流程

167. Dify AI 赋能，零基础构建商业级AI应用与工作流 - 慕课网\n - 哔哩哔哩

168. 运维平台，开源！完整开源，AI驱动的运维平台，彻底颠覆传统运维

你的AI总在上线后“翻车”？问题不在模型，而在缺少这套工程化落地框架

精选参考来源