Andrej Karpathy 曾让一个 Agent 对他自己的训练代码运行两天。它做了 700 次实验保留了 20 个超越基准的结果最终让模型训练速度提升了 11%。他总结了一句关键的话任何能被廉价评估的指标都可以交给 Agent 群来优化。回复率reply rate正是这样一个指标。我花了时间把这个思路落地到 Outbound 上构建了一个让系统从市场反馈中自我进化的闭环。核心思路是把 GTM尤其是 Outbound当成版本化代码来管理。不是让 Agent 直接发消息而是让它持续改进“打分规则”和“话术模板”而人类只负责最终把关。两个循环的分离整个系统包含两个相互嵌套的循环执行循环第一层感知市场 → 打分账户 → 根据信号写消息 → 发送 → 记录结果 → 从回复中学习。改进循环第二层读取上周结果 → 提出对打分规则或话术的修改 → 运行评估 → 打开 Pull Request 等待人类审批。本文重点讲第二层让系统像软件一样自我进化。Repo 结构让 Agent 能读能改系统从一个干净的仓库开始。结构决定 Agent 能做什么config/scoring.yaml决定哪些信号重要、权重如何prompts/存放不同场景的话术模板playsmemory/outcomes.jsonl记录每一次触达的真实结果最关键的文件evals/评估门fixtures score.py判断修改是否真的有效AGENTS.mdAgent 的“宪法”严格限定它能做什么先在离线环境跑通整个改进循环再逐步接入真实 CRM 和发送系统。构建改进循环的 8 个关键步骤1. 先写法律AGENTS.md在任何打分或提示文件之前先写AGENTS.md。它的唯一任务是收窄工作范围。没有法律Agent 会主动扩大范围多拉数据、改更多文件、调用更多工具、甚至自动化本该人类控制的环节。好的法律应该让人在审批 PR 前一眼就能看懂 Agent 被允许做了什么。保持简短且可执行。2. 把判断移入配置文件大多数 Outbound 判断原本存在于销售人员的脑子里。现在把它们显式写进config/scoring.yaml。示例结构简化# config/scoring.yamlsignals:downloaded_whitepaper:0.3visited_implementation_page:0.8competitor_comparison:0.4# ... 其他信号threshold:0.65这样修改就变成了可见的假设。团队可以直接争论某条规则而不是把销售判断变成工程重构。3. 把结果写成可学习的记忆memory/outcomes.jsonl这是整个系统最核心的文件。每一次触达结果落地时就追加一行{account:acme,signal:visited_implementation_page,outcome:replied,reason:asked about implementation timeline,timestamp:...}reason字段比单纯的 “replied / no_reply” 重要得多。它让 Agent 知道为什么某个信号有效或无效。4. 建立评估闸门evals/在 Agent 修改任何东西之前必须有一个它无法“解释掉”的测试。创建evals/fixtures.yaml包含已知的好坏案例和evals/score.py运行后输出一个清晰分数。好的评估门应该能抓住真实问题而不是只测明显赢的案例。5. 让 Agent 一次只改一个概念通过prompts/improve_scoring.md引导 Agent读取 outcomes分析哪个信号权重需要调整只提出一个概念的修改必须通过 eval 才能被接受第一次实验中Agent 想大幅提高某个高回复信号的权重但 eval 没通过被拒绝。这正是闸门的作用——防止听起来合理却实际无效的修改。6. 话术改进单独成道打分规则和消息模板的衰减速度不同应该分开优化。创建config/plays.yaml和对应的改进提示让 Agent 针对特定场景提出小幅话术调整而不是一次性重写整套语气。7. 以 Pull Request 形式交付变更Agent 编辑文件、运行评估、生成 PR 摘要后人类必须审批并合并。这是最后一道也是最重要的人类控制点。不要因为觉得审查是摩擦就跳过它。好的 PR 应该像团队成员写的清晰说明改了什么、基于哪些 outcome、eval 分数如何变化。8. 按周节奏运行不要每次有回复就触发改进。那会导致对单个 noisy 账户过拟合。让数据积累一周再运行改进循环。初期手动审查几次确认提案质量稳定后再放到定时任务。为什么这个模式有效传统 Outbound 的 playbook 是静态的靠人工经验迭代衰减快且难以规模化。这个模式把市场反馈直接转化为可版本控制、可评估、可回滚的规则变更。每次改进都有证据outcome、测试eval和人类把关。它不是让 Agent 取代销售而是让 Agent 负责“改进规则”这个重复且数据密集的工作而人类保留对最终判断和战略方向的控制。起步建议先在离线模式跑通整个 repo用历史数据或模拟 outcomes 填充 memory跑通改进循环确认 Agent 提出的修改都是小而可解释的等离线版本稳定后再逐步接入真实数据和发送系统。这个思路把 Karpathy 的“廉价可评估指标交给 Agent”落到了 GTM 场景构建了一个真正能从市场中学习的闭环系统。你当前 Outbound 流程里哪一部分的判断最适合先移入配置文件并让 Agent 帮你持续优化我是紫微AI在做一个「人格操作系统ZPF」。后面会持续分享AI Agent和系统实验。感兴趣可以关注我们下期见。
