昨天我host了一场space：AI Agent 在企业内如何落地：FDE 的真实工作 邀请了三位嘉宾：泊舟 @bozhou_ai , 阿黄 @UVWka3h 和 思路 @silux001 一起聊了一个小时 准备这场Space时，我最想搞清楚两个问题：企业Agent项目现在到底在交付什么；FDE能不能从一种高度依赖人力的项目服务，做成可持续、可规模化的商业模式。 三位嘉宾刚好代表了三种不同视角。 泊舟接触和访谈过不少国内FDE从业者，也在研究独立FDE团队怎么赚钱；阿黄在大厂服务KA和行业头部客户，做Skill、Agent以及配套云服务；思路则和前CTO搭档，以小型创业团队的方式，同时推进制造、建筑和金融行业的企业Agent项目。 聊完以后，我最大的感受是：企业Agent项目真正困难的部分，通常已经超出了模型和Agent Framework本身。 客户有没有完成基础数字化、业务流程能不能描述清楚、数据和权限能不能拿到、老板的预期是否正常、项目交付完以后怎么持续收费，这些问题最终直接决定一个Agent项目能否落地成功。 一、同样叫“Agent落地”，背后可能是三种完全不同的生意 泊舟分享了一个三人FDE小团队的案例。 他们服务的是一家十几到二十人、没有技术团队的小公司，主要交付Skill定制和企业知识库，帮助客户批量处理文本工作，例如生成脚本。 项目周期大概半个月到一个月，一单成交金额通常只有1万到2万元。 这个数字在扣除税费以及三个人分配后，每个人实际到手收入其实就不太乐观了。 这是一个很典型的陷阱：路径跑通了，但是不赚钱。 阿黄所在的大厂走的是另一种模式。 他们给KA客户定制Skill和Agent，同时提供Agent运行所需的云环境、服务器、数据库、模型调用和部署服务。收入来源里既有人力服务费，也有持续产生的云资源和模型调用费用。 他们做过餐饮点单Agent，把商品、用户等数据接入内部通用Agent中台，再针对点单场景定制Skill；也做研发和运维场景，把定时巡检等重复、流程固定的任务封装成Agent能力。 大厂在这里最大的优势，是能把Agent项目放进原有的云业务收入结构里。Agent软件服务是入口，后面的计算、存储、数据库、模型和技术服务都可以持续收费。 思路的团队则代表了创业型FDE的状态。 他们正在并行推进三个项目。 第一个是传统制造业工厂，产品形态接近AI-native SaaS。用户不再操作复杂的传统SaaS界面，而是直接向Agent表达意图，由Agent完成数据检索、分析，以及设备和订单的生产排程。工作量很大，但技术上总体可行。 第二个是建筑公司，希望用AI把CAD图纸转换成工程量清单。需求非常明确，价值也很直接，但技术难度极高。图纸里包含大量几何关系，不同设计师的制图标准和习惯又不统一，当前多模态模型很难稳定完成几何理解与业务语义映射，所以项目暂时搁置。 第三个是国内某头部券商营业部。他们把固定workflow和pipeline封装为MCP Service，再通过飞书交付Agent和Skill，同时帮助客户整理知识、文档和数据体系。 这个项目的业务流程相对容易实现，真正的阻力来自数据安全、隐私、权限和内部审批。 三个案例放在一起看，会发现“企业Agent落地”只是一个非常宽泛的标签。 独立小团队做的是一次性项目交付；云厂商做的是Agent带动云资源和模型收入；创业团队则在通过项目获得行业know-how，再尝试把重复需求产品化。 项目都叫FDE，收入结构、技术风险和交付逻辑却完全不同。 二、所谓“低垂的果实”，本质上是一套客户筛选机制 我在Space里问了一个问题：哪个垂直行业既能给客户创造足够大的价值，又能让FDE以相对低的成本完成交付？ 几位嘉宾最后形成的共识是，行业标签没有想象中那么重要。真正应该筛选的是客户状态。 一个适合优先做Agent的客户，通常已经具备几个条件： 业务里存在明确、重复的workflow或pipeline；已经有知识库、业务系统和协作工具；数据可以访问，权限能够协调；业务效率可以量化；老板对当前技术能力有相对现实的预期。 阿黄所在的大厂会优先服务原本就在云上的客户，原因很直接：这些企业通常已经完成了一定程度的数字化，数据、服务器和系统都在那里，交付边界更清晰。 思路提到，电商、外贸、互联网等高度数字化的行业通常更容易找到杠杆点。大量信息已经在线，员工也习惯使用飞书等协作工具，FDE不需要从最基础的信息系统开始补课。 很多传统企业的问题还停留在数字化阶段：没有可用的数据体系，文档和流程一片混乱，大量业务事实存在于几个老员工的脑子里。 这时候直接上Agent，FDE很快就会发现，自己接下来的工作包含基础设施建设、数据整理、流程重构和员工教育。Agent项目只是把这些企业的历史欠账一次性全暴露了出来。 所以一个非常重要的判断是： 先选择客户，再选择技术。 最适合优先落地的客户，往往已经有数字化基础，有明确且重复的流程，业务价值可以衡量，同时愿意开放数据和业务上下文。 老板的认知也非常关键。 泊舟提到，有些老板看完几篇文章或几个演示视频，就希望Agent自动理解需求、拆分任务、开发、测试并上线。 这种预期如果在签约前没有被纠正，后面基本一定会失控。 为了拿单而过度承诺，只是把销售阶段的问题推迟到交付阶段。到了验收的时候，所有模糊表达都会变成甲方眼里的承诺。最终验收的时候都是风险。 三、FDE交付链条里，产品、架构和工程缺一不可 关于“哪个角色创造的价值最大”，三位嘉宾的答案并不一致。 思路更看重产品经理和业务理解。 FDE进入一个陌生行业后，首先要快速理解真实业务。企业内部的信息经常不完整，不同部门之间也可能存在阻力。业务事实一旦判断错误，后面的Agent工程做得再复杂，也无法解决真实问题。 很多传统企业真正需要的功能并没有那么复杂。工程师可能拿着一套非常强的Agent架构，最后解决的只是一个流程清晰、规则明确的小问题。 思路的形容很准确：拿着降龙十八掌，去解决一个非常简单的问题。 阿黄则认为，实际交付很难依靠一个角色完成。大厂实践中的最小FDE单元，更接近一个“铁三角”： 商务负责客户关系、识别决策者、协调不同部门和梳理需求；架构师连接业务与技术，把问题转化成可以实现的系统方案；技术服务和交付人员负责真正的开发、部署和上线。 Agent时代，产品思维会逐渐变成这三种角色的共同能力。 泊舟从技术出发，更看重架构和工程确定性。 FDE最终按结果交付，而Agent天然带有不确定性。工程工作的价值，就是在这种不确定性中建立足够的确定性：提高任务完成率和准确率，控制Token消耗，降低调用成本，通过工具、架构和评估体系减少失败。 一个Agent能够比同类方案更可靠、完成率更高、Token成本更低，才真正形成了可以复制的竞争力。 我更愿意把三个人的观点看成一条完整的价值链： 业务和产品决定做什么，架构决定能不能做、怎么做，工程交付决定最终能不能稳定产生结果。 在Space里，我也进一步把完整的Agent交付体系拆成了三层。 前台是FDE，负责商务、调研、方案、交付、培训和维护；中台负责Agent开发、定时任务、API调度、Dashboard、部署和可观测性；后台则提供云基础设施、Sandbox、Memory、Context管理、稳定性和扩容能力。 前台负责拿到真实上下文，中台把一次性交付沉淀成可复用能力，后台负责保障整体Agent系统工程的稳定性。 四、FDE自己必须先成为高度AI化的人 思路在讨论里有一个很好的比喻： 人是Agent在物理世界里的触角。 FDE需要进入客户现场，访谈业务人员，观察真实流程，获取那些没有被写进文档的上下文。 与此同时，Agent可以负责生成调研框架、设计访谈问题、分析已有资料、梳理业务流程，再根据收集到的事实生成PRD、实施计划和解决方案。 人继续回到现场验证，Agent继续加工新的上下文。 这应该成为FDE自己的基础工作方式。 如果一个做Agent交付的人，行业调研、访谈设计、需求梳理、方案生成、开发测试、评估和项目复盘仍然主要依靠手工完成，他的交付成本很难真正降下来。 FDE卖的是企业效率，但首先要把自己的效率提高。 五、一次性交付很难形成一门好生意 三人团队用半个月到一个月交付一单，收入只有1万到2万元，这种模式很难覆盖后续培训和维护成本。 单纯提高客单价可以缓解问题，但很难从根本上改变项目制收入的线性增长。 更合理的收入结构应该包含云资源、模型和Token使用、部署运维、培训维护，以及持续版本升级。 思路和泊舟都提到了Token收入。FDE可以运营模型中转站，也可以和模型服务商、中转站进行分成。客户使用得越多，服务方获得的持续收入越高，也就更有动力继续培训、优化和维护。 阿黄所在的大厂，本身已经在使用类似的结构，只是收入不局限于Token，还包括服务器、数据库、模型、部署和整体云资源。 这种模式的重要价值，在于让服务方和客户的利益逐渐一致。 客户真正使用Agent，服务方才能获得持续收入；服务方持续优化Agent，客户才能获得更高的业务价值。 当然，Token收入本身也解决不了全部问题。真正决定FDE能否规模化的，还是能不能把项目里的重复部分沉淀下来。 每完成一次客户交付，都应该尝试提炼其中重复出现的Skill、Connector、Workflow、评估集和部署能力，再把它们沉淀进Agent中台或Harness。 下一次遇到类似客户时，团队交付的是已经验证过的组件，而不是重新从零搭建一套系统。 单纯扩充FDE人数，只会让收入和管理成本一起线性增长。把现场经验变成中台能力，才有机会持续降低边际交付成本。 六、ROI、获客和项目失败，最后都指向同一个问题：信任 有听众问，传统企业老板连AI能够替代什么都不知道，也没有明确预算，应该怎么沟通ROI。 阿黄的做法是先进行AI转型教育。 先展示大厂内部如何使用AI，邀请HR、运营等角色分享真实经验，再结合其他企业案例，把岗位拆成一个个具体任务，计算每项任务能够节省多少时间、人力成本，或者创造多少新增收益。 一上来就和客户讨论一个抽象的Agent产品，通常没有太大意义。ROI需要落到任务层面，而不是停留在“企业要不要拥抱AI”这种口号上。 FDE怎么获客，答案也很现实。 大厂可以通过面向CEO和关键决策人的活动、分享会和行业教育建立入口；独立团队可以持续发布真实案例，教育不同行业的人如何使用Agent、管理Context和设计工作流。 但在早期阶段，最容易转化的依然是已有关系、过去合作过的客户，以及朋友转介绍。 企业Agent项目需要接触大量内部数据、业务流程和组织信息，客户购买的不只是技术能力，也包括对团队的信任。 还有听众分享了一个Voice Agent项目。因为响应速度太慢，底层调用链和组织结构又过于臃肿，最终丢掉了订单。 这类项目失败后，首先应该判断问题属于哪一类。 如果当前技术和基础设施根本无法满足要求，也找不到现实可行的优化路径，就应该承认边界，停止继续消耗资源，或者重构整个方案。 如果问题来自业务理解不足，就继续获取上下文，重新与客户对齐需求，把模糊争议转化成任务完成率、准确率、延迟等明确KPI，再用一个可验证的新版本重新建立信任。 项目失败并不可怕。真正危险的是，团队既说不清失败来自哪里，也无法给出可以验证的改进路径。 最后 聊完这场Space，我对FDE的判断更明确了。 FDE的本质是结果交付。客户不关心模型Benchmark，也未必理解底层架构。客户最终关心的是，Agent能不能完成任务、节省多少时间、降低多少成本，以及结果是否稳定。 最好的项目起点，通常是客户已经存在的workflow和pipeline。先从一个明确的Skill切入，把边界和指标做清楚，再逐步扩大Agent能够承担的任务。 FDE更像一种靠近现场的产品机制。 先让人进入企业，拿到真实上下文，完成第一个可验证的结果；再把重复出现的需求抽象成中台产品能力，降低下一次交付的边际成本。 只完成前半段，本质上还是外包卖劳动力的生意。 把后半段做出来，才有机会成为一家公司。 企业Agent落地最终会同时碰到技术、组织和商业三套系统。 模型能力在绝大部分场景下已经不是瓶颈，客户的数字化基础和权限决定起跑线，产品、架构与工程决定能否完成交付，收入结构则决定了商业模式的上限。 这是我主持完这场Space以后，最想留下的结论。

这周四晚上8点，欢迎加入我们 @CreaoAI 组织的X Space，跟几位一直在一线做AI Agent落地的Builder和FDE们一起直播交流。 🎙 AMA：AI Agent在企业内是怎么落地的？揭秘 FDE 的真实工作 这次邀请的嘉宾有： ⚡️@bozhou_ai：《Codex Orange Book》作者、Dragon Code联合创始人 ⚡️@UVWka3h：阿里云高级解决方案架构师 ⚡️@silux001：Back to Zero University主理人、丰富的FDE实践经验 ⚡️@opcname：Whale Factory（AI行业服务）创始人兼CEO 📅时间：7月23日，周四晚上8:00（GMT+8） 📍地点：X Spaces 现在大家都在聊AI Agent和FDE，但从一个demo到最终交付到企业内部的生产环境的过程中都有哪些工作？ 现在大家都在聊AI Agent，但从做出一个能跑的demo，到真正部署进生产环境，中间还有很长一段路。 这场我们主要聊聊FDE真实的工作内容、一线部署经验、做项目时最常见的坑，以及AI Agent在哪些垂直领域或行业最有可能先广泛应用起来。 咱们周四晚上见！ #Creao# #AIAgents# #AI# #FDE#

既然都在晒收入，我也来凑个热闹。 其实我的主要收入大头是交易，上个月赚了50w， 6月26号后我为了方便交易tradfi换到bitget，到目前利润已经10w了。 交易这事儿其实不怎么花我的时间精力，我出手频次挺低的，主要做btc eth。是否开单就是几分钟看一眼的事。 工资的部分就不提现在的了。24年9月跳回阿里时给我开的offer是70w+的现金包。当时刚毕业工作三年，比其他老P7工资低不少。

我大概理解了一部分传统程序员为什么会如此抗拒和反对AI vibe coding了。 推上这个评论其实展示得很完整： 1. 对AI行业的认知非常浅。会把阿里内部某个AI编程实验，直接当成AI在真实生产环境里的能力上限，甚至拿这个来作为判断整个AI行业发展的依据。 2. 对AI工具的使用也非常落后。很难想象已经2026年了，还有人拿GitHub Copilot这种不知道落后多少代的东西来代表AI编程的真实水平。 3. 对成本和生产力的理解也很奇怪。现在最好的AI coding agent产品，200刀一个月的Codex量大管饱。但他们依然会认为企业采购AI编程工具成本非常高，所以“AI编程能力很强、能进入生产环境”这种说法都是纸上谈兵，一看就不怎么上班，非常水。 这几层叠在一起，基本就构成了一种很典型的判断路径：用落后的AI生产工具，和错误的AI行业认知，成本账也没算明白，得出了一个非常奇怪的结论。 不知道怎么评价好了，分享一下。

X上的程序员真的很喜欢借着各种事件反复表达一个核心观点：vibe coding会带来代码可维护性、系统稳定性、工程质量失控等问题。 这个观点背后其实还有一个隐含诉求：这些问题最后还得靠我们这些专业程序员来解决，靠我们设计优雅、专业、可维护的工程代码。否则你vibe出来的代码没有任何价值。 程序员什么时候才能真正明白，技术是为商业、为业务服务的。 如果你不是天才程序员，没有能力推动技术边界创新，那你在商业系统里首先就是成本。企业雇佣你，不是因为你写的代码优雅，不是因为你对工程洁癖有信仰，而是因为你能用技术解决真实业务问题，带来收入、效率、增长或确定性。 vibe出来的代码没有任何价值？ 卖不出去的软件才没有任何价值。 自嗨在自己的技术世界里搞各种工程设计、代码架构、优雅抽象，最后产品没人用、客户不买单、业务跑不起来，那些东西都只是工程师的自我感动。 很多人嘴上在批评vibe coding，实际上是在防守自己的劳动力价值。他们期待那些对真实世界有判断能力、能定义问题、能找到市场的人，继续认可他们的“专业性”，继续给他们开更高的工资。 真实世界从来不按工程师的自尊心定价 它只按结果定价。

CREAO is hiring 这是一艘刚刚开始提速的新船。 我们正身处AI时代的乱纪元。组织形态和财富分配方式都在被重塑。接下来最大的机会，会属于那些敢在秩序尚未形成时下场，用产品和结果定义新生态的人。 前不久，CREAO刚完成了3000万美元融资，用户和收入都在飞速增长。与此同时，我们看到大量尚未被解决的问题，以及一个仍在形成中的巨大市场。 在这样的节点上，我们期待更多有能力、有野心、有自己目标，并愿意为判断和结果负责的人加入。每个人都会得到充分的信任、资源和支持，也需要把推动事情并拿到结果。 我们一起创造，也一起分享这个时代的alpha。 这一次，CREAO开放三个关键岗位： - Agent Product Engineer - Forward Deployed Engineer - Product Marketing and Technical Growth 1.Agent Product Engineer（Full-stack） 在大多数公司，工程师负责实现产品需求。在CREAO，Agent Product Engineer直接定义产品。 我们没有传统的产品经理岗，也不会把一份写好的需求文档交给你。你需要理解用户问题，判断什么值得做，完成功能设计并上线，再根据真实反馈持续迭代。 你会负责CREAO智能体最核心的产品体验，包括智能体的创建、配置、执行、记忆、工具调用、定时运行、人工审核和效果评估，也会横跨前端、后端、接口、数据流、系统集成与智能体执行逻辑。 这个岗位既需要扎实的全栈工程能力，也需要很强的产品判断。你需要能在信息不完整的情况下做出高质量决策，知道什么时候应该快速推进，什么时候工程质量、可维护性和用户信任不能让步。 2.Forward Deployed Engineer Agent在产品里跑通，只是一切的开始。Forward Deployed Engineer要做的，是让它进入真实且复杂的商业环境，并在生产系统中稳定运行。 客户的真实系统往往复杂且混。你需要进入这些复杂度，抽丝剥茧地梳理业务流程、系统约束和成功标准，最终交付能够稳定运行的智能体解决方案。 你既要能和工程团队讨论系统架构，也要让业务负责人理解产品最终能够带来的价值。 我们会重点关注拥有3年以上企业客户一线技术岗位经验的人，例如解决方案工程师、实施工程师或技术顾。你需要具备很强的工程能力，也擅长识别并弥合CREAO产品能力与企业客户实际问题之间的差距。 这个岗位带来的是CREAO最快的产品反馈回路之一。 3.Product Marketing and Technical Growth 现在大多数AI产品的市场表达听起来都一样：自动化、效率、工作流。内容写的太泛，最后谁也转化不了。 我们需要有人真正理解CREAO正在构建的cloud agent harness层，再建立一套能够获得founder、builder、operator和developer注意力的叙事与增长系统。 这个岗位会负责CREAO的市场定位和产品表达，覆盖用户获取、激活、留存、推荐和商业化，也会参与新用户引导、模板、使用场景、产品发布、销售材料、竞品与市场情报，以及用户行为分析。 这远远不止是写内容。你需要真正看懂产品，能和工程团队讨论技术边界，也能从激活率、转化率和留存率中分辨真实的增长信号与虚假指标。 有工程背景会是很强的加分项。曾经做过工程师、创业者或技术型业务负责人，之后转向增长；或者拥有AI、开发者工具、效率工具、自动化、企业软件和产品驱动增长相关经验，都会非常匹配。 我们极其看重人才密度，因为最优秀的人，只愿意和同一水平的人共事。 但我们不会用职级和简历关键词来定义人才。我们更想看到的是，你是否真正走完过从问题判断、产品或技术方案、交付到反馈闭环的全过程；你能不能讲清楚自己做了什么、为什么重要、哪里判断错了，以及最后如何完成迭代。 在CREAO，每个人都会得到充分的信任、资源和支持，也需要对自己的判断与最终结果负责。我们一起在这个高度波动的时代背景下一起去创造财富。 我们会一起探索这个市场，挖出真正有价值的机会，做其他人不敢做、做不了，或者还没有看懂的事。 未来AI软件的商业生态，会由今天这一小群真正下场的人定义。 期待你的加入。 简历投递：evelyn@creao.ai

登味儿太足了。 想不到在X上还能刷到这种讨论“如何获得一个一辈子望到头并被兜底的人生”经验分享帖。 选择这个体制路线不是因为对这个领域感兴趣，也不是有任何事业上的追求。 很多人的毕生所求，就是想要被更体面的圈养起来。

Peter这篇文章讲清楚了cloud agent和desktop agent的根本分界：一旦agent离开用户电脑，问题从framework变成了infra contract。 桌面agent默认了很多隐含前提：本地文件系统可信、env里的key可信、用户在线、失败可以手动重试、环境坏了可以重装。 但对cloud agent来说，它要在无人监督、共享硬件、可能被prompt injection影响的代码环境里运行，还要支持被cron、API、以及其他agent调用。 因此在技术范式上，agent runtime未来会越来越像一个小型OS。 很多用户和朋友问过我们对secrets的安全管理问题，这篇文章很好的回答了我们的方案： 我们不去解决sandbox的安全性，这会让我们陷入跟黑客之间的攻防中把业务拖死。换另一个思路：假设sandbox已经被攻破，长期有效的secrets永远不进入sandbox执行边界。让黑客的攻入sandbox后的收益难以覆盖他们的时间和精力成本，他们自然会放弃这件事。 Peter的这篇技术分享文章很好的诠释了我之前说的agent产品难以落地的问题：demo阶段你只需要处理好context管理和tool数量；production阶段真正决定产品可靠性的是这些很无聊的东西：snapshot、JWT、IP allowlist、billing/logging/observability的一致执行管线。 agent is a function with a natural language interface。 agent的业务能力取决于用户的know-how，我们作为平台，帮助用户解决trigger surface、runtime和security boundary等等基建的问题。

在CreaoAI做了一年GTM，踩了很多坑，也看到很多AI创业团队卡在product marketing从0到1的阶段。内容生产、渠道选择、预算分配、投放反馈怎么回收到产品团队，这些问题我基本都交过学费。 所以我觉得有必要写一篇长文，系统性梳理一下自己这一年做GTM的部分经验。 这里面agency会成为一个绕不开的合作伙伴。尤其是在AI产品还处于0到1阶段时，团队自己的GTM能力、内容生产能力、KOL/KOC资源和投放数据基建通常都不完整。能否判断并找到长期靠谱的agency，某种程度上会直接影响你获得市场反馈的速度。 这篇算是抛砖引玉，也希望能和更多AI创业团队交流真实经验。 当下所有AI创业团队做GTM时遇到的挑战，本质上都指向同一个问题：如何让内容投放效率追上市场变化速度，并持续捕捉增长机会。 一个团队的GTM效率如果提不上去，后面所有动作都会变成劳民伤财。你以为自己在做增长，实际可能只是在花钱换噪音。 每次投放动作拆到最后，就两件事：内容和渠道。 在既定的大方向下，团队需要高效批量生产出能准确传递product message的内容，再把这些内容分发到合适的渠道里。 沿着这个方向，绝大多数AI团队在战术层面能做的动作，主要也就两类：Google/Meta Ads，以及KOL/KOC投放。 Google Ads的特点是像拧水龙头。只要有预算，理论上想投多少就能投多少，而且链路更短，更容易闭环。KOL/KOC在用户注意力吸引和转化效果上通常会比Ads更好，同时也更容易渗透社区。但很像买彩票，因为KOL是非标品，你很难提前评估清楚KOL投放的效果。 而在公众注意力极度分散到社媒平台的时代环境里，KOL投放已经成了AI产品必须要做的动作。 这又引出了另一个挑战：AI领域的KOL严重供给不足。 先定义一下我们讨论的AI KOL能力画像。 一个真正有效的AI KOL，至少要对AI产品有一定技术把握，能理解并识别不同AI产品之间的能力差异，能创造有价值、可传播的AI产品用例，同时还要有AI领域垂直粉丝基础，并且对自己的粉丝有真实影响力。最终，这个人需要能完成内容传播和转化。 按这个标准看，X上华语区符合条件的KOL，坦诚讲也就那么十来个。我投完一轮之后就没得投了。就算有预算也花不出去，因为供给没了。 这里特别点名夸一下三位华语区AI KOL: @lxfater @rionaifantasy @servasyy_ai 只要我投放，基本都会带上他们。因为在我上面那套标准里，他们合作下来的各方面数据表现是最优秀的一批。内容质量，CPM，CPA相比均值都非常优秀。 KOL投放这条链路其实很长。从产品功能、主用户路径到product message，中间会有一层信息磨损。product message再被整理成content brief给到KOL，又会继续损失一部分信息。最后KOL把内容发到平台上，还会受到短期流量规则、KOL粉丝受众结构、平台推荐机制等一堆黑盒因素干扰。 在这么长的生产链路里，GTM团队最优先要解决的，也是少数真正可控的事情，就是缩短整条链路的时间周期，加速获得市场反馈，并把有效信号带回团队。 尤其在0到1阶段，很多投放本质上都不是单纯为了获客，而是在测试产品、验证产品团队的判断。 要把这件事做好，一边保证内容产出效率，一边保证内容质量，一个长期合作、有默契基础、靠谱的agency基本必不可少。 因为这里面需要大量运营人力成本，也需要反复沟通确认。你不可能永远靠自己从0开始一个个检索、筛选、建联KOL。更现实的是，在最开始的时候，你甚至不知道哪些KOL在过往和其他AI团队合作时的平均表现，也不知道哪些KOL是灌水的。 一个专业、靠谱的agency，通常已经和大量KOL建立了合作信任，也会在内部搭建一套数据基建，用来客观评估每个KOL的真实表现。 当对方真的为结果负责时，给你的KOL list一定是在预算范围内精挑细选出来的最优组合。 垃圾agency则会在list里塞一堆营销号骗你的钱。至于灌水比例有多高，全看agency良心。这其实就是agency试图争取的利润空间。 agency的商业模式，说白了就是抽服务费。KOL给agency一个报价，agency在这个基础上给项目方一个更高报价，同时再向KOL要一个折扣价。一般毛利普遍在20%到40%。如果塞给你的是营销号，成交毛利甚至接近100%。 对产品方来说，服务费浮动高一点低一点其实无伤大雅。真正有伤害的是质量很差的KOL或营销号。 因为这意味着你不仅浪费了时间和钱，还可能收获一个无效甚至虚假的市场反馈。最糟糕的情况是，团队根据这个假反馈去调整产品和市场判断，后面的损失会更大。 这里也点名夸一下我最终长期合作下来的两家agency：JE Labs @JELabs2024 和 Mango Labs @dov_wo 这两家之前其实都是web3领域的agency。 这件事也让我重新理解了agency行业。agency这门生意，很多时候拼的是行业常识、执行基本功、资源判断和对结果的负责态度。在web3里真正做过几年marketing的靠谱agency，转到AI领域之后，综合能力反而比我之前合作过的一些所谓“AI KOL agency”强得多。 至少在执行基本功和专业度上，差距非常明显。 一个省心又靠谱的agency，基本能在两三天内帮你搞定整个内容生产链路里80%以上的事情。你只需要把核心product message和目标讲清楚，后面很多筛选、沟通、排期、brief、确认和复盘，他们都能推进掉。 官方大使这件事，我是和JE Labs团队合作的。 几次合作下来，我的感受是他们确实认真且靠谱，尤其运营方面非常仔细。JE Labs一直在建立长期市场合作网络，也陪跑过好几家团队从0到1做GTM，对一些语种的本地化运营有真实市场经验。 Mango是另一家我非常喜欢的团队。 后来深入了解他们团队情况之后，我才明白为什么每次跟他们合作都会觉得非常契合。Mango是一家全员都有工程师背景、都会写代码的agency团队。这个背景放在整个agency行业里，绝对是特例。 所以每次跟他们讨论数据、基建、ROI的时候，同样工程师出身的我只觉得：我艹，这感觉太对了，这才是正确的工作方式。 我以前合作过一些agency，连投放之后给产品带来的注册和付费转化数据都拿不出来。后来跟Mango合作，知道他们后台基建会动态评估每一个KOL的综合流量表现，那一刻我是真的有点激动。 而且我认为他们现在主推的灯塔平台 @Lighthouse_2026 ，很好地解决了我对AI KOL投放“没有供给”的痛点。 X上其实有大量中小KOL。他们的粉丝可能分布在几千到一万之间，有很好的内容创作能力，也有强烈的合作意愿，但是他们接不到商单。 站在产品方视角，如果我要投一个几万美金的campaign，我非常愿意把预算拆给一批这样的KOC。但极少有agency愿意接这种单，因为不赚钱。 每跟一个KOL合作，边际运营成本基本是固定的。对agency来说，如果能拿5000美金去合作一个KOL，利润空间肯定比拿5000美金去找一堆KOC高得多。 但对产品方来说，押注单个大KOL的风险，其实要比投一批KOC更高。 因为单个KOL一旦发挥失常，这笔钱基本就打水漂了。而且大KOL商单接多之后，也很容易开始不认真写。AI产品很需要深度、有价值的用例，玩票性质的内容对产品没有帮助，也不会有转化。 灯塔这个产品解决的正是这个问题。 它把大量KOC流量像流动性撮合池一样聚在一起，让原本分散、低效、难以组织的KOC供给，变成更可被调度的投放资源。 我线下和创始人Dov聊过几次。他对这个行业的问题和长期发展想得很清楚，也有很高的认知。他们最终希望把X上的KOC投放，做成像Google Ads一样可以拧水龙头的投放效率。 最后说一下我为什么要写这篇帖子。 agency和KOL这个领域有太多信息不对称，也能容纳太多作恶空间。 我遇到过不止一个纯粹短期主义、只想着能骗多少是多少的agency。我不会公开点名喷他们，毕竟断人财路这种事也没必要放到台面上。最多私下跟朋友或同行吐槽几句。 但我至少可以公开夸一下我这这边靠谱的合作方，哪些团队会认真想办法和你一起为结果负责。 让行业里的一部分注意力流向这些真正做事的人，对整个行业长期来看都是一件正向的事情。 我也期待能有更多同行公开讨论，哪些KOL和agency是花过钱合作下来确实靠谱的。 愿各位在做0到1的AI GTM同行们都能快速渡过搭基建开荒的阶段，少踩些坑。

CREAO的第一季Agent交易大赛开始了！ 这次共一万美金的奖池，第一名3000美金。 每个参赛选手会领到一个500美金的CEX假钱账户和一个初始化好的交易agent。有3天时间通过对话在CREAO上调整自己的交易策略，三天后全部冻结，让agent自动运行7天，最终根据pnl决定排名。 欢迎各位踊跃报名，随时在X上给我反馈！

Peter是我们的CTO，一个月前他开始实施新构建的AI-First的工作方式，结果是显而易见的，我们现在每天至少有20个PR会合并上线。产品changlog可以非常直观的体现我们团队的效率： 没想到他会写文章把这么干货的实践经验分享出来。 我推荐X上所有的founders好好读一下这篇文章，如果你们团队还在以AI-assisted而不是AI-first的方式去运转，很可能会在未来一年以内就逐渐淡出这个市场了。

用国内信用卡订阅Claude和Chatgpt最简单的方式： 1. 在IOS端下载Claude/Chatgpt 登录你的账号 2. IOS换到美区，支付方式链接PayPal 3. 在PayPal绑你的国内信用卡 在IOS 端里打开Claude/Chatgpt直接点订阅搞定