今日概览
今日内容高度聚焦 Harness 与 AI Coding 工程化：OpenClacky 让 Agent 自我改造、腾讯云给 DeepSeek Harness 补上规模化可观测、Multi-Agent 工作流降本 50%+、天猫沉淀 SKILL 研发四维最佳实践、吴恩达拆解 AI 工程师六块硬骨头，以及大淘宝主张从 Spec 驱动转向环境与验证驱动。
今日重点
1. OpenClacky：让 Agent 自我改造
OpenClacky 是一个更 toC 的 Harness：开箱即用 + 自造插件 + 扩展市场。核心思路是"Agent 能做什么、长什么样，由使用者决定"——用户用自然语言说"我要 xxx 功能"，OpenClacky 就会创建或修改 Agent、Skill、界面和整体业务逻辑，封装成可安装、停用、分享的 Agent 原生应用。
值得关注：
- LLM Wiki：把 Markdown、本地文件、双向链接、知识树和图谱原生放进工作台，导入资料后整理成长期维护的知识页。
- Multi-Agent 编排：描述最终目标，Leader 拆任务定角色、Worker 并行执行，同一面板可见进度与决策记录，可中途换模型、加角色。
- AI 调研助手：通过追问明确需求，搜索→研究→核验汇总，交付带出处的线索清单。
- 观点：model 能力不断膨胀，harness 成了新一代 UI，且能随需求不断迭代自己——“如何让 harness 自进化"成为新的下注点。
来源：赛博禅心
2. DeepSeek Harness 规模化踩坑实录：耗时、成本、失败到底该怎么查
腾讯云 Agent 可观测为 DSH 提供采集插件：以原生插件形态挂载，把散落的事件流还原为五层调用链（任务→turn→step→模型调用/工具调用），映射为符合 OpenTelemetry GenAI 语义的 Span，批量直传腾讯云，不经过 Collector、不插桩不改代码。
值得关注：
- DSH 自带会话轨迹、事件流落盘（zstd JSONL）、工具调用检索，但都是本机、单会话、实时；规模化后要跨会话聚合、跨机汇聚、长期留存。
- 一次 turn 一条 trace，多轮对话用 gen_ai.session.id 横向关联；重试不合并，每次真实调用独立 Span；中断也补发带错误码的 Span。
- 支持按状态、错误类型、Trace ID、Session ID、耗时筛选，详情页给调用树和错误根因定位。
- 价值：把"一批任务的整体表现、一段时间成本分布、几天前的一次失败"变成可查的结构化数据。
来源：腾讯技术工程
3. 吴恩达：构建和部署 AI 应用必须啃下这六块硬骨头
吴恩达研究大量招聘信息、做专家访谈后，把"会做 AI 应用"拆成六块能力：LLM 基础、数据工程、智能体系统、评估驱动开发、生产运维、机器学习基础。核心观点：AI 应用输出不确定，AI 工程师的核心能力本质上是在不确定中做决策的能力。
值得关注：
- LLM 基础：理解 token 化、逐步生成，才能判断任务能不能干好、什么情况下易错；何时微调、何时自己部署。
- 数据：RAG 只是起点，要判断哪些写进 prompt、哪些让模型自己查；向量索引/知识图谱/语义层各适其场；数据质量要持续维护。
- 智能体：固定工作流 vs 循环决策怎么选；工具、记忆、多智能体协作都要设计；原型到生产要考虑安全边界与对抗性输入。
- 评估闭环是区分优秀和普通工程师的最关键特质：先想清楚衡量什么，每次改动跑评估，用数据决定下一步。
- 运维差异：观测真实用户表现、数据漂移、统计化回归测试、成本与延迟控制。
来源：AI寒武纪
4. 靠这 10 个优化点，我们把 Multi-Agent 工作流成本降了 50% 以上
腾讯团队用 1 个 TL + 6 个子 Agent 驱动前后端全流程开发，先用 AgentLens 拆开成本：系统提示词、工具返回、历史消息是大头。围绕"让 AI 只看到当前需要的上下文、减少无关上下文、减少重复上下文"三原则，落地 10 个方向，中型需求全流程成本降 50%~65%。
值得关注：
- 六类 token 来源：系统提示词（40 工具 MCP Server 每轮多 10-15KB Schema）、工具返回、读取文件、长期记忆、历史消息（滚雪球大头）、用户提示词。
- 三原则：按需加载、别带无关的、同一份内容别多轮反复计费。
- 前置架构判断：先做规模预判（S/M/L），小需求单 Agent，中大型才进多 Agent 并行——拆分本身有成本。
- 经验：上游收集一次通过文档传递；最省钱的调用是不调用（确定性操作用 CLI/数据预取）；能并行不串行。
- 落地优先级：先架构拆分 → 度量 + SKILL.md 重排 + 全局 rtk（一个下午见效）→ 状态外化、并行化 → 代码图谱、CLI 替代 MCP 等中长期。
来源：腾讯技术工程
5. 浅谈 SKILL 研发的最佳实践——以百补详情助手为例
天猫团队已开发 50+ Skill，以百亿补贴详情助手（50+ commit）为例，从架构设计、研发效能、运行优化、呈现方式四维总结 Skill 研发实践。核心：不能持续迭代的 Skill 只是一次性 demo。
值得关注：
- 架构：本地 Skill 文件 + 远程 Agent，通过桥接脚本解耦——本地负责信息收集与结果呈现，深度分析交给远程 Agent。
- 渐进式披露：L1 元信息（name+description）每次加载决定是否激活，L2 SKILL.md 正文按需加载，L3 附件资源执行中按需读；SKILL.md 控制在 500 行内；description 要写得"有侵略性”，列明触发与排除条件。
- 控制调优：指令自由度与任务鲁棒性匹配（Control Tuning）。
- 运行优化：按需共享上下文、优先输出优质 HTML 报告。
- 结论：Skill 质量上限由上下文工程能力决定。
来源：大淘宝技术
6. 我对 AI Coding 的一点思考：从 Spec 驱动转向环境与验证驱动
作者认为 Coding 已被 benchmark 证明接近解决，但研发整体效率没同步提升——生码只占研发链路 20%~30%，按阿姆达尔定律，压缩编码环节的收益有上限。瓶颈已转移到编码之外的环境与验证环节，主张停止在提示词编排等易被模型迭代抵消的投入，把内部研发系统改造成 AI 可调用的环境。
值得关注：
- 一个需求编码 1 小时，上线却花 3 周（跨平台发布、封网合规）——瓶颈不在 Coding。
- AI 总优先解决"反馈公开、验证可规模化"的问题：编译/测试对不对机器自己就能判；企业环境没有公开反馈、验证成本高。
- 解法：构建可复现可调用的研发环境（Agent 能独立构建、启动、查日志、读监控）、分层验证体系（秒级/分钟级/人工判断）、把发布/实验/监控平台改造成 AI Friendly。
- spec 区分"约束"与"假设"：约束长期保存并自动检查，假设允许 AI 根据反馈自己调整——spec 划边界，不规定实现路径。
来源：大淘宝技术
趋势观察
- Harness 进入"自进化 + 可观测"阶段 — OpenClacky 让 Agent 自我改造、DSH 生态补可观测插件，同一周两条线都在回答"模型能力膨胀后 harness 怎么跟上"。
- 成本优化从"省 prompt"走向"省上下文" — Multi-Agent 降本 50% 的三原则（按需、去无关、去重复）与 SKILL 渐进式披露是同一套思路：上下文工程是新的性能调优。
- AI Coding 的下一战场在编码之外 — 吴恩达六块硬骨头和大淘宝"环境与验证驱动"殊途同归：评估闭环、可验证反馈、AI 可调用的研发环境，才是持续放大模型红利的地方。