vivo提出AgentHarness设计框架，技术产品经理需定义任务模型与执行契约

在大模型驱动的智能体（Agent）产品开发中，传统以 Prompt 和界面为中心的产品设计模式正面临系统性挑战。vivo 互联网产品团队成员 Meng Disheng 近期发表文章，系统阐述了面向技术产品经理的 Agent Harness 设计框架，核心观点是：产品经理必须深度参与任务建模与执行契约定义，才能确保 Agent 产品从需求到交付具备工程可实现性与可验证性。

Agent 产品与传统功能模块的关键差异在于其非原子性与长周期特性。一个典型 Agent 任务往往涉及多步骤串行/并行调度、外部工具调用、用户介入确认、异常处理与状态回溯，无法用简单的“输入—处理—输出”模型概括。例如，“根据用户反馈生成改进建议并提交至工作系统”这一目标，需拆解为数据读取、清洗去重、聚类分析、影响评估、历史匹配、建议生成、冲突校验、报告输出及人工确认等至少九个环节。每个环节的执行顺序、依赖关系、失败策略与数据流向，都必须在需求阶段明确定义，否则将导致研发阶段反复返工或运行时行为不可控。

这种结构化定义避免了将调度逻辑隐含于 Prompt 中，使任务流具备可复现、可调试与可视化追踪能力。

任务模型则进一步将用户目标抽象为独立实体，脱离会话上下文束缚。一个标准 Task 包含 taskId、userGoal、inputRefs、workflowVersion、owner 与 runRefs 字段；而每次执行实例 Run 则记录 runId、currentStep、status、outputs、approvals 与 errors。该模型支持同一目标多次执行、版本迭代与结果比对，为 A/B 测试与效果归因提供基础。

工具契约部分强调工具应视为“业务动作协议”，而非单纯 API 封装。每个工具需明确定义 inputSchema、outputSchema、permission、sideEffect 与 timeout/retryPolicy。尤其关键的是 sideEffect 字段——用于标识该工具是否修改外部系统状态（如写数据库、发通知），这直接影响事务一致性与回滚策略。产品经理需协同后端评估工具副作用范围，并在任务流中设置检查点与补偿机制。

权限分级采用四级模型：L0（只读自动执行）、L1（读数据+权限校验）、L2（内部产物+来源追溯）、L3（改业务数据+授权审批）、L4（高风险外部操作+强制审批）。权限绑定基于 Subject（主体）+ Resource（资源）+ Action（动作）三元组，且越界或过期时需重新授权。例如，向客户系统推送建议属于 L3 级别，需在用户确认环节触发二次鉴权。

结果协议要求每条输出必须附带 evidenceRefs（证据引用）、assumptions（前提假设）与前提条件，确保结果可追溯、可验证。验收标准不再依赖主观判断，而是通过结构化数据比对、外部系统记录核查或模型生成路径回放完成。例如，一份“问题分类结果”需关联原始反馈记录 ID、聚类算法版本号与阈值参数，以便复现与审计。

失败与观测模块则定义七种应对策略：补全、授权、重试、拆分、降级、修正与恢复，并通过 traceId、taskId、runId、workflowVersion、retryCount 与 errorCode 构成完整可观测链路。经验表明，约 30% 的 Agent 任务失败源于未明确定义超时边界或忽略外部服务抖动，而清晰的失败策略可将平均修复时间缩短 60% 以上。

该框架的现实意义在于弥合产品与工程之间的认知鸿沟。过去，产品经理常止步于“用户想要什么”，而工程师负责“怎么实现”；在 Agent 场景下，二者必须共同定义“任务如何被约束地执行”。vivo 团队已在内部多个智能客服与运营辅助 Agent 项目中落地该方法论，任务首次通过率提升 45%，线上异常回溯耗时下降 70%。

值得注意的是，Agent Harness 并非替代现有编排框架（如 LangChain、DAGsHub 或自研工作流引擎），而是为其提供上层产品语义规范。不同技术栈可基于同一份 Harness 协议生成兼容实现，从而保障产品逻辑一致性与跨平台迁移能力。

随着 Agent 从单轮问答走向复杂业务闭环，产品设计范式正在发生根本转变：从界面交互导向转向任务工程导向。技术产品经理的角色也需相应升级——不仅要懂用户场景，更要理解任务调度、权限边界与结果可信度的构建逻辑。这套设计指南为行业提供了可复用的方法论起点，但其真正价值仍取决于团队能否在实践中持续迭代契约细节与验收标准。