企业官网建设流程全解析

Andrej Karpathy 曾让一个 Agent 对他自己的训练代码运行两天。它做了 700 次实验，保留了 20 个超越基准的结果，最终让模型训练速度提升了 11%。

他总结了一句关键的话：任何能被廉价评估的指标，都可以交给 Agent 群来优化。

回复率（reply rate）正是这样一个指标。我花了时间把这个思路落地到 Outbound 上，构建了一个让系统从市场反馈中自我进化的闭环。

核心思路是：把 GTM（尤其是 Outbound）当成版本化代码来管理。不是让 Agent 直接发消息，而是让它持续改进“打分规则”和“话术模板”，而人类只负责最终把关。

两个循环的分离

整个系统包含两个相互嵌套的循环：

1. 执行循环（第一层）：感知市场 → 打分账户 → 根据信号写消息 → 发送 → 记录结果 → 从回复中学习。
2. 改进循环（第二层）：读取上周结果 → 提出对打分规则或话术的修改 → 运行评估 → 打开 Pull Request 等待人类审批。

本文重点讲第二层：让系统像软件一样自我进化。

Repo 结构：让 Agent 能读能改

系统从一个干净的仓库开始。结构决定 Agent 能做什么：

• config/scoring.yaml：决定哪些信号重要、权重如何
• prompts/：存放不同场景的话术模板（plays）
• memory/outcomes.jsonl：记录每一次触达的真实结果（最关键的文件）
• evals/：评估门（fixtures + score.py），判断修改是否真的有效
• AGENTS.md：Agent 的“宪法”，严格限定它能做什么

先在离线环境跑通整个改进循环，再逐步接入真实 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和系统实验。感兴趣可以关注，我们下期见。