--- title: "他的 Agent 昨晚替他把公司运转了一遍，你的早会才刚开始" source_url: "https://mp.weixin.qq.com/s/TXk9JNSnBDCjm3VzvtcJGg" author: "深思圈 / 深思SenseAI" created: 2026-05-26 type: article tags: [ai-agent, startup, context, eval, skills, harness, operations] sha256: "" --- 他的 Agent 昨晚替他把公司运转了一遍，你的早会才刚开始 原创 深思圈 深思SenseAI 2026年5月26日 12:37 浙江 同一个市场，同一个月成立的公司。 早上九点，公司一的运营负责人还在翻昨天的支持工单，分析师在重建上周的数据面板，创始人正在开一个三天前就挂起来的客户投诉晨会，没人知道怎么解决。 公司二的创始人，那时候已经在迭代产品了。 夜里，智能体分类了工单，刷新了面板，在通话录音里找到了埋藏的流失风险。创始人早上看完简报，问题已经解决，他开始思考下一步。 这是 Stepan Gershuni 在 cyber.fund 上发的一篇创始人指南里的开头。他的论点很简单：真正的差距，不是谁雇了更多人，是谁的公司学得更快、迭代得更快。每天快一点。几周后差距开始拉开。几个月后，只有一家会活下来。 How to Build an AI-Native Startup — cyber.fund 创始人指南封面 传统创业 vs AI 原生创业的组织结构对比：前者是创始人与多人的全网格协调，后者是少数人通过 Context·Agents·Evals·Skills 驱动 01 先画地图 第一步，不是找工具，不是选模型，是画工作地图。 把过去两周公司里重复发生的所有工作列出来：客户通话整理、线索调研、支持工单分类、产品测试、候选人初筛、发票审核、竞品监控……创始人的日历里通常有 20 到 40 项这样的东西，诚实列下来会发现，有 10 到 15 项是你没意识到已经变成例行工作的。 然后按自主程度分级。 最底层是纯人工——战略决策、关键招聘、法律签字，这些不碰。往上一层，AI 起草人来审批，比如投资人更新、合同红线、定价页改写。再往上，AI 执行人来监督，入站分类、会议记录路由、线索丰富都可以放这里。最高一层是在明确限制内自主跑——竞品监控、夜间报告、简单异常检测。 有一个反直觉的规律：频率胜过重要性。 这让我想起健身房里的道理——最有效的训练计划，不是最科学的那个，是你能每天坚持去的那个。每周写一次的投资人更新，一年只有 52 次机会发现自己写得不好。每天跑十次的工单分类，一年有 3650 次机会让评估系统抓到失败模式。低频的工作哪怕看起来更重要，你永远攒不够样本来知道自己做得好不好。 无聊的工作流通常赢。频率胜过光鲜。 他还提到 C.H. Robinson 的例子，挺有警示意味的：他们试过把每天 10,000 封邮件的入站分类推到全自主，结果退回到了 AI 起草人审批。量太大了，单条错误路由的代价看着小，但藏在总量里根本发现不了。 说白了：如果团队自己都说不清什么算做得好，那这个流程就还没到能交给机器的时候。 02 把记忆装进代码库 他把 context 定义为「AI 原生创业公司的操作记忆」——公司对自己的一切了解，放在智能体能读到的地方。 我第一次真正理解这件事，不是读这篇文章的时候，是看一个老厨师做菜。他用的锅、灶、油、盐，和隔壁新开的馆子完全一样。但他知道这口锅哪个位置火最旺，知道今天的姜水分偏大所以要多煸一下。这些不是「技术」，是他和这批食材、这口锅之间积累的默契。 Gershuni 说的 context 就是这个。模型是锅，context 是你和你业务之间的默契库。同一个模型，读了你三个月客户通话提炼的公司，和一个刚接入 API 的公司，输出质量差的不是一个级别。模型会换代，就像锅会升级。但那层「知道客户说再考虑考虑其实意思是价格太高」的提炼，是跟着你走的。 他建议从一个 Git 仓库开始——有版本历史，可比较差异，人和智能体都能读。第七天的工作区可以只有几个文件：CLAUDE.md、context/company.md、context/product.md、context/customers.md、context/lessons.md。控制在 40-60 行手写内容，紧凑的「应该避免什么」清单，比 400 行 AI 生成的内容更有用。 一个让我印象深的数字：Anthropic 的 MCP 代码执行工作展示了一种「服务器文件夹」加载方式，把 context 占用从约 15 万 token 降到了约 2000 token——削减了 98.7%。省钱省到这个程度，财务看了会想请你吃饭。 有一件不太被提到的事：一定要把原始数据和提炼数据分开。通话录音是原始数据；那次通话里做的决定、客户提出的反对意见、续约风险——这些是提炼数据，是智能体真正需要查询的东西。把两者混在一起，你会淹在录音里，永远搭不起那一层真正有用的东西。 然后是溯源。每个智能体的总结，都必须能追溯到源头——哪个录音，哪张工单，哪个数据库行。没有溯源，公司里会开始充满无法核实的「听起来很对」的总结。第一次有人发现某个自信满满的答案是错的，整个智能体层的信任就崩了。 有溯源，争议一秒内就能解决——点进去，看源头。 03 选最轻的那个 做完 context，很容易想把所有工作都塞给智能体跑。 千万别。 他说得很直接：不是所有流程都需要智能体。最好的 AI 原生系统，是脚本、AI 辅助人工、确定性工作流、和智能体的混合体，用最轻的工具处理当前的工作。 步骤确定的，用脚本就够了——导出报告、转 CSV、跑测试、校验 JSON，别浪费智能体的算力。输出需要判断才能放出去的，比如投资人更新和定价文案，让AI 辅助人工。步骤已知但链条长的，用工作流串起来。只有路径真的无法预设时，才请智能体上场：排查生产 bug、调研市场、处理复杂客户案例。 每个智能体外面，必须套一个防护层（harness）。六个阶段：预检（在消耗 token 之前检查权限）→ 计划（拆解任务，暴露步骤）→ 审批（人或评判模型把关）→ 执行 → 验证 → 记录。 防护规则要写进代码和配置，不能只写在提示词里。提示词里写「不要删生产数据」不是安全边界。 2025 年有个 Replit 事件，一个编程智能体在会话途中把生产数据库清空了。那是现成的教训：提示词指令不是安全边界，只有代码层面的限制才是。 04 什么叫做对了 技能和评估（evals）是整个系统的引擎。前面都是铺垫。这里才是真正复利的地方。 技能是一套可复用的指令加示例，用于一个重复性任务。手跑两遍，然后把重复的部分编码。每个技能需要：范围、输入、需要加载的 context、步骤、输出格式、示例、升级规则、负责人、运行日志。 如果文件没说它接受什么、返回什么、什么时候求助、谁来维护，那它是个很长的提示词，不是一个技能。 评估是让技能复利的东西。一旦有了可用的 eval，提示词调整就变成可选项了：一个小型反思模型提出改动，eval 给改动排名，最好的那个自动上线。没有 eval，每次迭代都是一场口味之争。 他用客户通话整理举例：拿 30 个历史通话，让业务负责人标注每个应该提取什么。机械检查——名字对不对、金额和合同匹配吗、跟进日期在正确的周内——这些是确定性的，直接判断。LLM 评判负责剩下的部分：这份通话简报听起来像那次通话吗？ 跑大概 50 次之后，你会发现两个固定的失败模式。通常是那两件你之前没想到的事，不是你担心的那些问题。 要监测的核心指标：接受率。低于约 70%，技能还没准备好提升自主程度。接受率低的时候，直觉是改提示词——几乎从来不是这个问题。通常是四件事：运行时加载更多 context、收窄技能范围、文件里加更多已完成的示例、或者为智能体不该接的任务写更清楚的升级规则。 05 创始人先上 要让团队转向新的运作方式，最快的路是创始人自己先展示。 不是在会议室里讲 PPT，是在公司的真实 context 下现场演示。展示从日历、收件箱、Slack 过夜拉取的晨简报；展示昨天通话的客户合成；展示智能体根据需求文档开的测试 PR；展示从最新指标包自动生成的投资人更新草稿。 Jack Dorsey 据报道在 Block 围绕这些工具重组之前，每天早上花几个小时亲自使用这些工具。领导层亲自用过，才有了那次效率重组的决定。 入职也要变。每个新成员在第一次会话结束时，都要有一个当天可以用的输出——清理后的客户简报、支持宏、测试 PR、定价页评审。Ramp 的 Glass 工具靠这个规则，从每天 20 个日活用户涨到了三个月内的 700 个。不产生真实工作的培训，下周就被忘了。 招聘门槛也高了——因为有些以前需要人的工作，现在是一个技能。招人时，测的不是知识，是判断力。给候选人一个在给定时间内靠人工做不完的任务，看他们怎么指挥智能体做完。你招的是判断力、品味、和当智能体走偏时的纠错能力。 这些能力，以前就很值钱。现在，更值了。 06 每周进化 AI 原生创业公司每周改进一次自己的操作系统。 他把循环分成内环和外环。内环让现有工作更好——降低每次运行的成本，缩短周期，减少事故，减少审查时间。外环寻找下一步——新客户群、产品方向、竞争对手动态、流失风险。后台智能体全天候给外环输送候选项，人来决定追哪个。 有一个硬规则：任何代码都不能自动合并，没有智能体可以直接写入生产环境。就连 Cursor，在 2026 年初大规模跑云端自主智能体时，合并前仍然保留了人工审查门槛。这个门槛，是让其他一切能安全扩展的前提。 真正的天花板在哪里？他说得很清楚：不是模型能力，是能不能写出 eval。如果你能把「什么是好输出」编码成二元标签、评分标准、或者几个业务指标，循环就能在整个公司的规模上运转。如果不能，再强的模型也填不了这个空。 智能体能力很少是真正的瓶颈。如果你能把好输出编码成标签、评分标准或业务指标，循环就能以整个公司的规模运转。如果不能，再强的模型也没用。编码能力有帮助，但不是瓶颈；一个能可靠标注输出好坏的领域专家，可以跑完整个循环。 07 护城河是什么 这篇文章最后一句话，我读了两遍。 「每个人都有同样的模型；操作系统是秘密武器。」 说得干净。但读完我的第一反应，不是「对，我要赶快去做」，而是——真的这么简单吗？ Gershuni 说护城河是纪律——画地图、搭 context、写 eval、每周跑循环。这个我不完全认同。他把问题框定成了「执行纪律」，但我觉得他漏掉了一个更根本的东西：判断什么值得编码，本身就是一种稀缺能力，这个能力没法被方法论覆盖。 大多数创始人高估自己做的事的战略含量。他们不是不知道 L1 到 L4 的分法，是不愿意承认自己 80% 的时间在做 L3 的事。瓶颈不是纪律，是自我认知的诚实度。 而这个东西，没有任何框架能替你解决。 还有一件我还没想清楚的事：如果操作系统真的是护城河，那是不是意味着——一旦某家公司的 context 和 eval 积累到临界点，后来者就永远追不上了？不是赢家通吃市场份额，是赢家通吃学习速度本身。先跑起来的公司，每天比你多学一点，而且学习速度还在加速。这不是线性差距，是指数差距。 历史上每一个「指数差距不可逆」的论断，最后都被某种范式跳跃打断过。我不知道这次是不是不一样。 有一件事我觉得可以确定：如果你今天还在争论「要不要用 AI」，你争论的已经不是工具选择的问题了。不参与的代价，每过一周都在变大——大到某个时间点，你可能连代价有多大都看不见了。 资料来源：cyber.fund · Stepan Gershuni (@cyntro_py) · How to Build an AI-Native Startup · May 2026