今日概览
今天三篇恰好构成一组正反论证：大淘宝给出"Agent 要接管工作，靠的是把业务知识结构化"的正面答卷，云栖大会 Skill 展示"给 Agent 提供能力"已变成一句命令即可分发的轻量形态，而 Code is cheap 那篇从演示日志出发，论证不加业务建模、只套个 Agent 壳撑不起企业级 SaaS。
今日重点
1. 改变世界前先认识世界：Ontology 决策结构化实践
淘天集团商家财务团队交出的答卷：三个月内他们在 Agent Room 里创建并完成 120+ 需求 / 工作项，几乎所有类型的工作都能由 Agent 接手——不止需求开发到上线，还包括数据订正、工单处理、业务接入和业务运维。核心主张是"模型和编排工具会不断迭代，但结构化的业务知识才是决定 Agent 能否稳定产出高质量决策的核心壁垒"。
值得关注：
- 工作全托管不是"把固定流程自动执行一遍"，而是要求 Agent 每一轮都回答一组结构化问题：当前任务属于什么业务对象和业务线（domain / bizLine / object）、需要补哪些证据（required_slots / evidence_matrix）、哪些路径看似合理但不能走（rejected_routes）、现在能执行什么动作（action / workflow / skill）、结果证明到了什么范围（proof_scope）、下一步交给谁（next_owner）。本质是 Observe → Decide → Act → Verify → Next，每一步都有可审计、可复现的结构化产物。
- 为什么不预先画 workflow：真实工作不是一条固定线，而是一张动态变化的图——工单可能一开始看似是页面问题，取证后发现是账单对象、发票状态、离线回流或权限配置问题。文章对比了四种 workflow 形态的优劣：手工拖拽（泛化差）、自然语言 Skill（证据不足时容易继续推进）、内置脚本 Skill（解决"怎么做"但不解决"该不该做"）、预设场景 workflow（无法穷举真实场景）。结论是流程节点不该是第一性原理，真正该结构化的是决策。
- decision_function 的形态：把"专家怎么判断"沉淀成"槽位 + 图遍历 + 路由规则"的可执行程序，字段包括触发场景、起始 ontology 对象、必填证据槽、取证步骤、沿图派生结论、按槽值路由、拒绝路径（避免被关键词误导），输出 graph_path / filled_slots / unknown_slots / rejected_routes / evidence_matrix / proof_scope / next_owner。整个过程不依赖 Agent 的"自觉"——证据不足不推进，结论不超过 proof_scope。
- 知识分四层：Business（业务对象）、System（系统落地）、Delivery（交付门禁）、Governance（治理机制）。团队采用碎片化积累模式，每天沉淀一个小决策产生复利，而不是一次性建成大图谱。
- 对底层换代是免疫的：作者把同一套知识库和决策函数在 qoder 系列、Codex、Claude Code 上都跑过真实需求，模型换过 Opus、GPT-5.5、GLM-5.2、Qwen 3.8——平台和模型都换了一遍，输出稳定性没变。因为"红冲工单要取哪些证据、哪条路绝对不能走、预发门禁之后交给谁"这些判断既不在模型权重里，也不在 harness 的编排里，它们在 ontology 和 decision_function 里。
来源：大淘宝技术
2. 云栖大会 Skill 上线：带着你的Agent来参会
云栖大会 Skill 正式上线千问 AI 平台：4 大展馆、120 多场分论坛，一句话帮你逛展台、听论坛。它基于开放的 Agent Skills 标准开发，Codex、OpenClaw、Claude Code、Cursor 等支持 Skills 的 Agent 都能用（推荐千问办公和 Qoder）。
值得关注：
- 交互方式极简：在常用 Agent 里发送
npx skills add QianWen-AI/apsara-conference-2026完成安装，之后直接用自然语言提问，不需要记命令。 - 三类用法：查展馆展区展台（按技术方向或行业兴趣出发找重点）、按时间/地点/主题筛选并订阅论坛（撞期时先了解每场讲什么再决定）、查询直播与交通住宿餐饮门票签到等参会信息。
- 已开放摘要服务的论坛，结束约 3 小时后可领取内容摘要，并能继续追问核心观点、重要发布与技术亮点。
- 分工表述很克制：“人负责交流、体验和判断，Agent 负责找、筛、记和补。“这也是 Agent Skills 标准值得注意的地方——给 Agent 提供能力正在变成一种可分发、跨客户端的交付形态。
来源：阿里云开发者
3. 从一堆 Agent 演示日志说起：为什么说’套壳 Agent 就能做 SaaS’是个荒谬的幻想
作者翻内部某款桌面端 Agent 研发版本的演示日志，从表面看效果挑不出毛病：能分析合同风险、能算现金流拐点、能用 Python 渲染深色科技蓝的内嵌 SVG 和单文件 HTML。但顺着调用链路、Token 消耗和执行状态查下去，工程上的违和感非常重。
值得关注：
- “惊艳效果"踩在工程临界点上：那些硬核业务 Demo 的首轮 Prompt 不是普通用户写得出来的，而是长达三五百字、写满防御性限制的"小合同”——“区分已确认回款和预计回款……不要编造回款日或审批结果……原始文件不要覆盖……没有的标记’待确认’"。这是技术人员提前把系统里缺失的防御逻辑人肉写进了 Prompt。换成真实用户的常规输入（如"我需要先优化你的工作逻辑”），模型当场抓瞎，反手弹确认框找上下文。
- 本地特权环境撑不起云端多租户：Demo 跑在本桌面上、直读 .xlsx/.docx/.pptx 才"看着能打”，但宿主机带点脏变量就能冲垮内置 Skill 执行环境，往工作区外写一步沙箱立刻报错，前端提示"定时任务创建成功"而后端连外部消息通道通不通都没验证过。一旦搬到云端多租户 SaaS，网络隔离、环境兼容、文件权限、数据隐私和跨系统授权会瞬间卡死这套链路。
- 算力花在"看起来炫酷"上：单单给界面换个主题（“换个科技蓝配色"“自包含纯内联 SVG”），Agent 要通读原文件、写脚本改样式、再验证、再输出，单轮上下文拉到 13.8 万 tokens（输入 13.7 万，输出几百字）。虽然前缀缓存命中率稳在 99%+ 兜住了延迟和成本，但底层业务逻辑半点没变，吞吐全耗在样式修饰上。
- 范式冲突：传统 SaaS 是确定性中枢（关系型数据库 / ACID → 状态机 & 业务规则引擎 → RBAC 权限 & 审计追踪），幻想中的 Agent SaaS 是概率黑盒（模糊输入 → 大模型概率判定 → 易漂移的临时脚本 → 不可预测的草稿）。四维死穴：边际成本（几乎为 0 vs 每次数万至数十万 token）、计费预期（按人头订阅可预测 vs 算力黑洞）、责任边界（系统对状态流转负责 vs"仅供参考请人工复核”）、最终交付物（实际业务状态变更 vs 草稿/预览）。
- 结论不是否定 Agent：严肃 Agent 的约束文件末尾都有同一条边界条款——“除非存在明确授权与用户确认，下列动作必须停在 draft/preview：不得执行付款、不得正式核销、不得替公司决定签约”。Agent 的真正优势是作为灵活的操作员，但操作员绝不等于业务系统本身。“承认大模型的边界，老老实实啃下那些看似枯燥的业务建模与工程基建，远比整天幻想着拿一个 Agent 壳去’重新发明 SaaS’要体面得多。”
趋势观察
- 胜负手在业务知识层，不在模型或 harness 层 — 大淘宝那篇把话说得最直白：模型层和编排层都在被快速替换，业务知识层没有；同一套 knowledge + decision_function 换个平台换个模型跑真实需求，输出稳定性不变。这和前几天的"判断与生成解耦"是同一条线——能力会商品化，被结构化的判断不会。
- 决策结构化 > 预设 workflow — “流程节点不应是第一性原理，真正该结构化的是决策”。不为场景画流程图，而是让 Agent 每阶段运行 decision_function 按证据动态长流程，并用
rejected_routes和proof_scope把"证据不足不推进、结论不外扩"写成硬约束。 - “套壳 Agent 就能做 SaaS"被当场证伪 — Code is cheap 那篇从演示日志里扒出的三条硬伤（防御性 Prompt 人肉补逻辑、本地特权环境不可迁移、样式修饰吃掉 13.8 万 tokens）说明：跳过业务建模的捷径，最后都要在真实世界里还回去。它和大淘宝那篇其实是同一枚硬币——正经做的门槛就是业务知识建模。
- Agent Skills 标准开始横向铺开 — 云栖大会 Skill 用一句
npx skills add就接入 Codex / Claude Code / Cursor / Qoder，说明"给 Agent 提供能力"已从厂商内建走向可分发、跨客户端的交付形态。可预期的下一步是这类 Skill 变成像 npm 包一样的基础设施。