#产品级系统

16小时前

Agent = Model + Harness？不！它严重低估了实际工程复杂度。应该是： Agent = Model + System！ Harness：围绕模型的提示工程、上下文管理、工具调用等"脚手架"。⚠️ 被过度关注，仅占实际工程的30%。 System：完整的产品级系统：认证、多租户、资源隔离、审计、成本管控等。✅ 真正决定产品成败的70%。三大核心批判 1. 问题域错位：Harness 源于特定场景 Harness 工程的模式（如文件系统内存、Sub Agent 架构）主要来自 Coding Agents 这一特定形态： · 单用户 · 终端环境 · 本地文件系统将这些模式推广到通用 Agent 产品会导致系统性失配。 2. 制造本不存在的问题作者列举 Harness 工程创造的"伪需求"： · AGENTS.md 文件作为记忆：单用户、无并发、无查询能力；应该用数据库 — 原生支持SQL、访问控制、持久化 · 虚拟化文件系统：用文件抽象包裹数据库，多此一举；应该直接暴露数据库，LLM 写 SQL 比写 bash 更可靠 · 用户级沙箱：隔离成本失控，无法规模化；应该做系统级资源配额与隔离 3. 忽视经典系统工程问题真正的生产级 Agent 必须解决已存在数十年的工程难题： · 多租户：50 人团队如何安全共享 Agent？ · 基于角色的访问控制：谁有权触发哪些操作？ · 资源隔离：如何防止单个租户耗尽全量 token 预算？ · 审计日志、审批流、成本管控这些不是 Harness 层能解决的，所以作者主张新框架： Agent = Model + System Harness 工程对 Coding Agent 这一特定场景仍然有效，但不应泛化为通用 Agent 架构的最佳实践。

#agent #model #Harness #System #工程复杂度 #产品级系统 #提示工程 #上下文管理 #工具调用 #认证 #多租户 #资源隔离 #审计 #成本管控 #问题域