Cloudflare CTO Dane Knecht：智能体时代的安全、内容付费与企业流程重构

一、嘉宾背景

Dane Knecht 是 Cloudflare 首席技术官。在这期由 Sarah Guo 和 Elad Gil 主持的 No Priors 访谈中，他讨论了三组相互关联的问题：AI 如何改变漏洞发现与防御，智能体如何参与网络内容经济，以及企业如何将 AI 纳入实际工作流程。他的职责横跨互联网基础设施与公司内部的技术部署，也构成了这些判断的背景。

嘉宾资料列出的相关工作包括互联网安全、面向企业客户和免费用户的保护，以及 AI 与智能体部署、数据安全和零信任。访谈没有展开他的完整履历；理解其观点，更直接的依据是这些职责，以及他在节目中介绍的 Cloudflare 实践。

Knecht 将 Cloudflare 持续承担的使命概括为保护互联网，帮助人们发布内容并扩大其服务规模。他说，随着 AI 的使用，防止数据泄露和未经授权的访问已成为当前重点。如何让员工和开发者用好 AI，同时控制数据与访问风险，贯穿了整场讨论；其中对 Cloudflare 自身实践和成效的描述，则来自他作为公司管理者的观察。

二、本期主要内容

Knecht 首先谈到的是严重安全事件出现得越来越密集。他说，过去类似 Log4j、Shellshock 的事件，可能一年才触发一次全员响应，如今相近严重程度的问题每周都会出现，其中一些尚未公开。这是他基于自身工作视野的观察；节目没有提供统一的统计口径，不能将其视为已经独立核实的行业频率。

漏洞发现者也在变化。Knecht 提到，近期一些重大漏洞由使用智能体的高中生发现，漏洞赏金为这类探索提供了动力。他将能力的扩大归因于模型、运行框架以及人使用这些工具的技巧。这里首先发生的是发现能力的扩散，发现者的身份本身并不能说明其具有恶意。

同样的能力扩散，也在改变网络访问。按照 Knecht 的描述，人类和智能体正在共用一套主要为人类阅读和广告展示设计的网页。人会阅读内容、观看广告，参与网站原有的收入循环；智能体则可以迅速读取大量页面。为机器增加页面转换层会消耗 token，而现有 API 只覆盖部分可用信息。如何交付内容、由谁承担站点成本、内容提供者如何获得补偿，因此成为同一个问题的不同部分。

Knecht 提出，可以通过智能体小额支付补偿内容提供者，并将广告 CPM 收益作为可能的定价参考。不过，访谈没有说明，按千次展示计算的广告收入应如何换算成单次读取价格。他还介绍了内容变现网关、智能体钱包、稳定币相关支付基础设施，以及与 OpenAI 合作的 Signals 项目。按他的说法，Signals 旨在帮助智能体发现新内容，减少重复抓取。

这些安排距离形成稳定的内容经济还有多远，访谈没有给出采用规模、结算表现或创作者收入作为依据。Knecht 对成功的定义很具体：支付收入应能覆盖创作者的基础设施费用，并支持其生活。这是他设定的目标，尚不能视为普遍实现的结果。他也承认，让个人智能体顺畅访问内容、完成任务所需的技术和商业模式，目前还没有完全到位。

企业内部的对应实践是 Cloudflare OS。Knecht 说，它起初是为了解决 AI 使用过程中内部数据和客户数据的流动与治理问题，随后纳入公司已有的知识和工作原则，供智能体遵循。Cloudflare 将其发布为参考架构，其他公司可以在此基础上分叉、修改。

据 Knecht 观察，市场销售等业务团队以及行政职能团队，对 Cloudflare OS 的使用比工程团队更活跃。他的解释是，围绕具体业务提供指导和数据访问，比给员工一个空白聊天框、让他们自行寻找用途，更容易融入日常工作。这反映的是 Cloudflare 的内部使用情况，也说明了他为何把公司实践和数据治理放在同一套系统中。

三、核心观点：推理、例子与边界

Knecht 对安全形势的判断，建立在一个过渡期预测上：未来约十八个月，企业需要集中投入安全工作，此后软件生产率有望提高。他的理由是，AI 能够检查大量存量代码，安全检查也可以嵌入后续开发。主持人随即提出另一种可能：软件产量同样在增长，旧漏洞的清理速度未必赶得上新问题的产生速度。十八个月因此是 Knecht 对过渡期的估计，而不是安全负担必然下降的时间表。

对于关键基础设施可能大面积失效的前景，他没有那么悲观。他看重危机中的行业合作，也认为从“城堡与护城河”式的网络边界防御转向零信任，改善了防御基础。在他的描述中，安全控制围绕设备和数据流展开，组织不再默认内部网络天然可信。这有助于解释他的信心，但零信任本身不能消除软件漏洞，也不能说明所有组织都已做好准备。

谈到代码，Knecht 把减少攻击面放在首位：先判断能否用更简单的设计、更少的代码实现目标，再考虑形式化验证、更安全的语言和运行时。减少潜在出错位置，是这套思路的起点。不过，AI 生成代码的倾向有时恰好相反。他承认，早期 AI 编程系统容易写得冗长、复杂；主持人也提到，自己会要求模型以十分之一的复杂度重做。代码能够运行，并不意味着其中的设计都有必要。人的设计判断仍然包括提出替代方案、删去多余结构，而不只是检查生成结果。

Cloudflare 内部的 Codex 文档，体现了另一种工程约束。它汇集工程 RFC 以及安全、可用性方面的实践，再提炼成智能体可以遵循的原则。这里的 Codex 指公司内部的规范集合：原本需要同事传授的经验被写下来，供智能体在执行任务时使用，并配合独立复核、性能测试和安全测试。文档提供共同依据，测试与复核则检验具体结果；如果生成与复核重复的是同一套假设，仅有规范仍不足以证明风险受到控制。

漏洞发现与修复应如何排序，是访谈中分歧更明显的地方。Knecht 预计将一支红队扩展到四五支，希望更大的发现压力推动工程团队自动化修补。主持人追问：为什么不先完善补丁流程？前者寄望于压力促成改变，后者关注处理能力能否先跟上。访谈没有证明，增加漏洞发现一定会带来及时修复。Knecht 同时反对暂停发布，主张安全与交付并行，必要时减少成本优化等其他工作的投入。他把 AI 同时视为安全压力的来源和可能的防御工具，但两者能否抵消，仍取决于实际执行。

客户邮件的例子，则把流程重构落到了具体任务上。原来，产品经理需要请 BI 确定目标人群，由营销团队调整表达，再交给营销运营发送。按照 Knecht 的描述，新的工具允许员工直接描述人群、撰写邮件并调整为公司口吻，最后由经理批准发送。改变的是跨团队交接和任务执行方式，审批责任仍然保留。这个例子说明自动化可以重组一项完整任务，但节目没有提供节省时间或改善质量的测量，也不足以据此判断所有跨团队流程都适合合并。

对于安全能力是否应逐步开放，Knecht 的出发点是谁能获得防御工具。他认为，恶意参与者和资源充足的组织终究会取得这些能力，限制访问反而可能让其他人缺少自保手段。他也表示，Cloudflare 会将针对部分重大漏洞的防护提供给免费用户和付费客户。这些主张体现了他对广泛提供安全能力的重视，但开放后的滥用治理仍未得到完整解答，平台提供的防护也不意味着应用中的漏洞已经全部修复。

四、学习与应用

客户邮件案例提供了一个审视工作流程的起点：选择一项交接多、反复返工的任务，梳理从输入到最终行动的全过程，明确谁提供数据、谁生成内容、谁批准、谁执行。中间操作可以尝试合并，对外发送则应保留明确授权，并检查目标人群或表达出现错误时能否被发现。评价这类实验，需要记录交付质量、等待时间和人工返工；界面或操作步骤减少，并不足以证明任务完成得更好。

Knecht 鼓励员工主动尝试改造自己的工作，也介绍了一个早期内部做法：员工通过邮箱提交需要完成的任务，服务返回相应的 skill 文件，实习生参与了这些文件的编写。它让实际工作中的困难有了明确入口，也把一次求助转化为可以重复使用的操作说明。其他组织可以借鉴任务征集、结对制作和持续修改的方法，招聘规模则需要另作判断。

他还说，与实习生共事的经理采用 AI 更快。Cloudflare 此前有一批约二百名实习生，后来决定在一年内招聘约一千名。这些数字说明了公司扩大投入的幅度，但“带实习生的经理采用更快”仍是内部观察，不能排除团队原有差异，也不能据此认定增加实习生就会直接提高生产率。

模型分工同样需要通过实际任务验证。Knecht 描述的安排是由前沿模型负责规划和复核，执行环节则可能使用开源模型；尽管他希望实现智能路由，目前的任务分配仍相当依赖手动操作。团队可以在边界清楚的任务上比较这种配置的成本、错误率和修改负担。如果执行结果需要频繁退回重做，单次调用更便宜未必意味着总成本更低。规划与复核分开，也不自动保证复核能够独立发现问题。

费用管理的重点，是让消耗与产出能够对应。Knecht 反对 token 使用排行榜，主张看员工实际交付了什么。他介绍的每日支出提醒机制是：约三百美元时通知使用者本人，五百美元时通知经理，一千美元时通知副总裁。这套机制让不同层级及时看到费用；具体阈值是否合适，则取决于团队预算、任务价值和试验阶段。高消耗本身不能作为有效采用 AI 的证明。

工程团队可以把 Knecht 对简化软件的要求落实到生成前后的设计检查中：要求说明实现为何必要、是否存在更简单的方案，将公司的安全和可用性原则写成智能体能够遵循的要求，并配合独立复核、性能测试和安全测试。如果扩大漏洞发现投入，也应同时明确修复负责人、优先级和验证方式，检查新增发现能否得到处理。这些是从访谈观点延伸出的实践建议，其效果仍需验证。

流程重构还涉及人员变化。Knecht 承认，Cloudflare 与 AI 相关的重组包括与同事告别，并将重组解释为重新思考工作流程的机会。这段陈述没有证明相关人员离开的必要性，也没有建立重组的净收益。评估职责与交接如何调整时，仍需分别审视流程效果和人员影响，区分预测、内部观察与经过验证的结果，并持续检查失败、返工和责任归属。

来源

• 原始节目：Democratizing Security for the Agentic Web with Cloudflare CTO Dane Knecht