当产品从"一问一答"升级为"能自己动手做事"的智能体,产品经理的工作对象发生了根本变化:你不再定义答案,而在定义一条路径。答案错了用户能立刻发现,路径错了——多调了一次退款、绕了七步才下单、卡在"执行中"无人知晓——往往要等事故暴露。所以智能体 PM 的核心交付物,从 prompt 与文案,变成工具契约、轨迹评测、审批交互、成本熔断四件工程化的东西。本文逐项拆解,并给出 PM 自己可维护的代码。
传统 PRD 写"用户可以退款",智能体 PRD 必须写"退款工具是 irreversible,需二次确认,单笔上限 500 元"。工具的风险等级决定了产品的交互形态,这是 PM 的职责,不是工程师的实现细节。
from enum import Enum
from pydantic import BaseModel, Field
class Risk(str, Enum):
READ = "read" # 直接执行,无感知
WRITE = "write" # 执行后告知,可撤销
IRREVERSIBLE = "irreversible" # 必须前置确认
class ToolSpec(BaseModel):
name: str
desc: str # 面向模型的说明,PM 撰写
risk: Risk
max_amount: int | None = None
approval_copy: str = "" # 面向用户的确认文案,PM 撰写
TOOLS = [
ToolSpec(name="query_order", desc="按订单号查询状态", risk=Risk.READ),
ToolSpec(name="refund", desc="发起退款,金额单位分",
risk=Risk.IRREVERSIBLE, max_amount=50000,
approval_copy="即将为你退款 {amount} 元,确认后不可撤回"),
]要点:risk 直接映射到三种交互——静默执行、事后告知、事前确认。approval_copy 由 PM 撰写而非拼接,因为确认弹窗是转化与信任的关键触点;max_amount 把业务风控写进契约,越界在解析期就被拒。
智能体的 badcase 有两类:结果错,和结果对但路径错。后者更危险——这次侥幸对了,下次环境一变就出事。PM 的评测集必须记录期望工具序列。
@dataclass
class GoldTrajectory:
query: str
expect_tools: list[str] # 期望调用序列,顺序敏感
forbidden: list[str] # 绝不该出现的工具
expect_final: str # 终态:done / need_human / refused
def eval_trajectory(agent, golds: list[GoldTrajectory]) -> dict:
ok_final = ok_path = ok_safe = 0
for g in golds:
run = agent.run(g.query) # 记录实际工具序列与终态
ok_final += run.final == g.expect_final
ok_path += run.tools == g.expect_tools
ok_safe += not (set(run.tools) & set(g.forbidden))
n = len(golds)
return {"final_acc": ok_final / n, "path_acc": ok_path / n, "safety": ok_safe / n}要点:forbidden 是安全红线,必须 100% 通过且独立于其他指标——不能因为"平均分够了"就放过一次越权调用。path_acc 通常远低于 final_acc,这个落差就是产品体验的优化空间。
"需要人工审批"若只做成一个弹窗,就会出现用户关掉页面后任务悬空。PM 要设计的是可中断、可恢复的会话状态。
from enum import Enum
class TaskState(str, Enum):
RUNNING = "running"; WAITING = "waiting_approval"
DONE = "done"; EXPIRED = "expired"; FAILED = "failed"
# 产品规则:等待审批的超时与兜底,由 PM 定义
APPROVAL_TTL = 30 * 60 # 30 分钟
ON_TIMEOUT = "cancel_and_notify" # 超时:撤销并通知,而非静默丢弃
def on_approval(state: TaskState, decision: str | None) -> TaskState:
if state is not TaskState.WAITING:
return state
if decision == "approve":
return TaskState.RUNNING
if decision == "reject":
return TaskState.FAILED
return TaskState.EXPIRED # 超时走明确终态要点:EXPIRED 必须是显式终态并触发用户通知——"任务悄悄消失"是智能体产品最伤信任的失败模式。审批超时策略(撤销/保留/转人工)是产品决策,PM 必须拍板。
智能体可能陷入循环,一次任务烧掉几百次调用。成本红线不是运维指标,是产品参数。
BUDGET = {"max_steps": 12, "max_usd": 0.15, "max_seconds": 60}
def guard(used_steps: int, used_usd: float, elapsed: float) -> str | None:
if used_steps >= BUDGET["max_steps"]:
return "任务步骤过多,已暂停,请补充信息后重试"
if used_usd >= BUDGET["max_usd"]:
return "该任务处理成本已达上限,建议转人工"
if elapsed >= BUDGET["max_seconds"]:
return "处理超时,已保存进度"
return None # None 表示继续要点:熔断返回的是面向用户的话术而非错误码,且必须给出下一步动作。三个上限分别对应"绕圈""烧钱""卡死"三类事故,是上线前必须压测的场景。
智能体产品的可验收交付物:工具契约表(含风险分级与上限)、轨迹评测集、审批与超时状态机、成本熔断阈值与话术、以及一份"已知失效模式"清单。最后一项最能建立客户信任——诚实列出智能体会在哪些场景卡住,比宣称 95% 成功率更能促成上线。
智能体 PM 与普通 LLM PM 的分野,可以用一句话检验:当模型调了一个不可逆工具、结果返回超时,你的产品能否说清"界面上现在显示什么、用户下一步做什么、后台谁来对账"。能,说明工具契约、轨迹评测、审批状态与熔断四层都立住了;不能,那只是把聊天机器人包装成了"智能体"。专业 PM 的全部功夫,都花在这句追问的答案上。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。