今日概览
今日五篇全部聚焦同一主题：如何让 Agent 从"单次能用"走向"长期可靠"。腾讯 Forge Memory 解决工程判断跨任务延续、得物 Delivery Harness 把生成速度变成稳定交付、火山 OpenViking 让上下文跨工具在线、大淘宝项目 Harness 形成知识飞轮、腾讯确定性 Harness 给高风险决策加执行纪律。
今日重点
1. Agent 每次接新任务都像新人第一天入职？带你告别"一次性智能"
腾讯提出 Forge Memory 框架：解决 AI Coding Agent 跨任务时工程判断无法延续的问题。代码回答"现在是什么"，不总能回答"为什么如此、什么变化会使它不再成立"——设计理由随实现演进而消失被称为 knowledge vaporization。Forge 把需求约束、代码探索、实现修改、测试验证和任务后知识沉淀组织进同一闭环。
值得关注：
- 工程判断跨任务流动有三个断点：代码能否表达选择理由、任务经验能否成为长期知识、已存知识能否在正确任务中真正影响判断。
- 保存对话、文档、检索只是基础，Forge Memory 处理的是知识资格：哪些经验值得长期保留、哪些知识适合进当前任务、用完后如何接受代码/验证/团队持续校正。
- 通过读取准入与沉淀准入机制，让知识在后续任务中被复用、验证并持续校正。
- OpenSpec 明确任务做什么，Harness 让 Agent 在工程上下文与约束下执行，Memory 把有效工程判断带入后续任务。
来源：腾讯云开发者
2. 得物小摊 AI Native 演进实录：用 Harness 构建可控 AI 交付
得物一人全栈复盘：AI Native 的上限不是生成速度，而是把"生成得快"变成"交付得稳"——可检查、可复验、可追责。一次需求要穿过 H5、运营后台、Node 网关和 Go 服务多个运行时，作者从"写更聪明的 Prompt"转向 Delivery Harness。
值得关注：
- 四个可复用组件：Version Contract 锁定事实与边界、Execution Boundary 限制改动半径、Evidence Gate 控制状态跃迁、Repair Loop 把真实反馈变成下次默认生效的规则。
- 触发点是一次语义分叉：拼团页面进度数字取"最低成团数"还是"当前可售库存"——猜错会顺着接口、页面、海报和验收用例一路传下去。
- 核心：模型负责生成，系统负责边界与证据；每一次状态跃迁都必须有合同和证据支撑。
- 产研协作基本单元将从文档交接变成可验证假设：产品定义业务不变量，研发翻译成接口合同/状态机/门禁，AI 补全方案并回放证据。
来源：得物技术
3. 换工具、换 Agent，不换上下文：OpenViking 让研发 Context 始终在线
火山引擎 OpenViking 是面向 AI Agent 的统一上下文数据库：不是另一个 Agent，而是位于不同 Agent 背后的共享 Context 层。研发一天要在群聊、CLI、飞书文档间切换，真正麻烦的不是工具多，是 Context 跟不上人——每换一个窗口都要重新复制资料、补充 Prompt、回忆历史决策。
值得关注：
- 三类资产统一组织：代码仓库/项目文档/Review 规则存为 Resource，个人偏好/历史判断/Code Learnings 沉淀为 Memory，可复用工作方法组织为 Skill，都放在统一 viking:// 路径下。
- L0/L1/L2 分层读取：先读摘要、再看目录概览、最后按需加载完整内容；任务结束后 Session Commit 从对话和执行中提取经验写回长期 Memory。
- 支持 Hermes、OpenClaw 等主流 Agent 接入（MCP/CLI/API/SDK）。
- 核心主张：工具跟着任务变化，Context 始终跟着人——不是被反复复制的公共 Prompt，也不是某个 Agent 私有的聊天历史。
来源：字节跳动技术团队
4. AI 驱动研发体系的实践和思考
大淘宝营销交易团队四个月实践总结：业务 AI 研发的真正瓶颈是上下文而非模型能力。从 AI 辅助编程 → Coding Agent → 项目 Harness 三级演进。Price360-KB 项目把业务知识、源代码、项目规则、流程 Skill、质量门禁和验证证据放在同一工作空间，用 CLI/MCP 连接工作项、环境、配置、日志和数据库。
值得关注：
- 公式演进：Agent = Model + Harness（通用）；业务研发 Agent = Model + Coding Agent 通用 Harness + 项目 Harness。
- “本地优先：Agent + 文件夹 + Git”：迭代过程本身就是知识飞轮，项目无需完美知识库即可启动，在真实迭代中持续完善。
- 产品、开发、测试共同提出目标、约束与决策，人的重心从逐步指导操作转向业务判断、方案选择、结果验收和高风险授权。
- 未来：模型和通用 Agent 能力提升后项目 Harness 会收缩，但业务知识治理、规则决策边界、验证标准不会消失——技术人员将更接近 FDE 角色，深入业务并对端到端交付负责。
来源：大淘宝技术
5. 一文讲透确定性 Harness
腾讯提出确定性 Harness：高风险决策场景里模型是概率性的、结论必须是确定性的。它做四件事：把策略文档拆成阶段化代码流水线、FlowTracer 把每一步输入输出分支留档、IsFinal 能下结论就提前终止、统一网关加缓存稳住外部依赖。LLM 在这套东西里不是主角，是可随时插拔的判断单元。
值得关注：
- 工单审核案例：九个阶段、几十个条件分支、六步顺序校验，判错就是客诉——“模型能生成答案，却无法为答案背书”。
- 三大痛点：黑盒不可解释（审单人员/用户/监管问为什么驳回）、循环失控（死循环卡住流水线）、证据链断裂（事后找不到"这一单凭什么这么判"）。
- 分级置信度：L1 模型直接出结论、L2 模型给建议人工拍板、L3 模型只能给 SOP 禁止自动执行。
- 该不该上 Harness 的判断：这个 Agent 的结论需不需要对某个人、某条规则、某次检查负责？需要就值得为"确定性"付工程成本。
来源：腾讯云开发者
趋势观察
- 记忆与上下文的"资格管理"成为新焦点 — Forge Memory 的知识准入、OpenViking 的三类资产分层，都在回答"什么值得留、什么时候给谁看"——存储能力早已不是瓶颈，治理才是。
- Harness 从"让 Agent 能跑"走向"让结论能负责" — 得物 Delivery Harness、腾讯确定性 Harness、大淘宝项目 Harness，三层 harness 都在把状态跃迁、证据、边界变成可复查的链路。
- 技术人员的角色向 FDE 迁移 — 当模型和通用 Agent 吞掉编码，人守住的是业务理解、系统连接和对结果的责任——上下文和规则会成为新的"护城河"。