--- title: "如何为 Agent 设计产品？" source: wechat url: https://mp.weixin.qq.com/s/mlajGBnYpugyxjTDc7JGNA ingest_date: 2026-07-04 vxc: 56 stars: 4 sha256: 98227515a6762fc18670450ba7ce318b9556460bfed4128536285c2429cb342a --- # 如何为 Agent 设计产品？ **来源**: 架构师 **发布日期**: 2026-04-26 **原文链接**: https://mp.weixin.qq.com/s/mlajGBnYpugyxjTDc7JGNA --- 架构师（JiaGouX） 我们都是架构师！ 架构未来，你来不来？ 前面我们聊过一个说法： 像 Agent 一样看世界 。 这句话我自己一直挺喜欢。 它不是让人把自己想象成模型，也不是故意把事情讲玄。落到工程里，其实就是一句很朴素的话：别只按人类用户的习惯设计工具，要看模型实际怎么读信息、怎么选择工具、怎么犯错、怎么从错误里恢复。 那会儿我更多是在讲 coding agent。工具职责要单一，信息要渐进式披露，输出要反复读，别幻想一个提示词能管住所有行为。 这两天读 Salesforce Headless 360 的发布，我一开始也差点把它当成普通新闻：又一批 MCP、API、CLI，顺手蹭一下 Agent 热点。 越往里看越觉得不是这么回事。 但多看几遍，思路又往前走了一步。 以前的问题是：怎么为一个 coding agent 设计工具。 现在问题变成了： 如果 Agent 真的成了产品的新调用方，我们该怎么为它设计产品？ 前面几篇文章，其实都能接到这里。 写 Harness 的时候，我们聊的是模型外面那套主循环、工具、上下文、权限和验证。写 Skills 的时候，我们聊的是团队经验怎么变成 Agent 能按需加载、能执行、能修订的过程资产。写 CLI 那篇 时，我们聊的是为什么 --help 、stdout、stderr、exit code 这些老东西，反而很适合 Agent。写 长任务 和 Prompt Caching 的时候，我们又绕回同一个问题：什么东西该稳定，什么东西该动态增长，什么东西该从上下文里拆出去。 放到软件产品里，这些问题没有消失，只是换了对象。企业软件、协作工具、财务系统、CRM 这类有流程和权限的产品，会更早碰到这个问题。 以前我们是在给 coding agent 搭工作台。 现在是在问：产品自己，能不能成为 Agent 可靠工作的工作台。 Salesforce 这次发布，表面上抛出的问题是：以后为什么还要登录一个 CRM？ 我更愿意把它翻译成另一句话： 软件产品正在从"给人操作的界面"，变成"给人和 Agent 共同调用的运行底座"。 这不是 UI 死了。UI 还会在审批、确认、配置和异常里长期活着。变化的是：UI 不再天然等于产品本身。产品还要有另一张脸：Agent 能不能理解它、调用它、被它约束，也被它帮助。 所以，我想聊的不是"给产品加一个 Agent 入口"。更准确地说，是产品能力要怎么被重新整理：让 Agent 看得懂、调得动、出错能恢复，做完还能留下记录。 说白了，以前软件主要怕人不会用。 你还得多怕一件事： Agent 以为自己会用，结果一路猜着用。 ## 太长不看 如果只记一句，我会这么说： 为 Agent 设计产品，不能停在把页面换成 API，或者赶紧接一个 MCP。更实在的做法，是把产品能力整理成 Agent 能理解、能调用、能被约束、能被审计的动作。 几个我现在比较有体感的点： - • Salesforce Headless 360 是一个很好的观察对象：它把平台里的能力暴露成 API、MCP 工具或 CLI 命令，首批超过 100 个工具和技能。 - • 有意思的地方不在"无头"这个词，而在数据、流程、权限、业务逻辑和信任层还留在平台里，只是允许 Agent 从更多入口调用。 - • 这和我们之前聊过的 Harness、Skills、过程资产能连起来看：模型越强，外面的工具、上下文、权限、验证和回滚越重要。 - • 之前聊 CLI 时说过，Agent 很吃 --help 、 --json 、exit code 这类稳定接口。现在这个要求正在从开发工具，扩散到更多软件产品。 - • 类似 Agent Script 这样的设计，是在给"概率系统 + 确定性流程"补一个中间层；Testing、Evals、A/B Testing、Observability 也会变成企业 Agent 的基础设施。 - • 计费也会被牵动。当干活的不一定是人，而是 Agent，按席位、按登录、按页面活跃度理解 SaaS 价值，就会越来越别扭。 - • 落到产品设计上，我会先看五件事：能力有没有拆成动作，说明是不是机器可读，权限和审计有没有下沉，失败能不能恢复，反馈能不能进产品改进。 ## 先从“像 Agent 一样看世界”说起 先把上次的思路接上来，不然这次的讨论容易断。 Claude Code 团队那篇 "Seeing like an Agent" 给我的最大启发是：工具设计不能只靠人类直觉。 人看一个界面，会读按钮、读文案、补上下文，出错了会自己猜下一步。Agent 不这么干。它看到的是工具名、参数、上下文片段、返回值、错误消息，外加一组行为约束。同一个功能，对人来说可能只是一个按钮，对 Agent 来说，最好是一个职责清楚、可调用、可恢复的动作。 Claude Code 团队反复试过让模型"好好提问"：把问题塞进 plan 工具、让模型输出固定格式，最后最稳的版本是一个职责极其单一的 AskUserQuestion 工具：模型负责调用，界面负责渲染选项，用户点选，任务继续。 成功点不在工具复杂，而在职责清楚。 这点很像我们平时写系统：一个接口同时干五件事，人还能靠经验绕过去；Agent 就很容易卡住，或者更糟， 假装没卡住 。 类似的还有渐进式披露：别把所有文档塞进系统提示词，先给索引，相关时再让 Agent 自己拉细节。 Agent 会读规则，但它需要在正确的时刻拿到正确粒度的规则。 现在，这套思路开始从开发工具往更多产品外延。企业软件只是最先被推到台前的那一类，因为它本来就有数据、权限、流程和审计。 之前写 《 MCP 之后，CLI 又成了王？ 》时，我其实已经有一点这个感觉。 --help 为什么对 Agent 友好？命令行本身没有多神奇，它好在把一件事讲得很机器可读：这个工具叫什么、参数是什么、怎么调用、失败了怎么看。stdout、stderr、exit code 也一样，天然给了 Agent 一个很清楚的反馈回路。 到了产品层，这个问题只是换了形态。Agent 调用的入口可以是 CLI，也可以是 API、MCP、Hosted Server，甚至是产品自己的 Agent。名字不同，要求差不多：能发现、能理解、能执行、能知道成败，出了错还能退回来。 过去软件默认的链路是： 用户 → UI → 平台 现在多了一层： 用户 → 用户自己的 Agent → 产品自己的 Agent / 工具层 → 平台底座 入口多了一个，调用方也变了。为 Agent 设计产品，第一步就是承认这件事：产品不能只有给人看的界面，也要有给 Agent 看的说明书。 从"像 Agent 一样看世界"到"为 Agent 设计软件" ## 别只看“无头”，关键在于守住 这次被讨论最多的，是 Headless 360。 官方公告标题很直接： No Browser Required 。 抛开市场语言，这次发布要说的其实只有一句：企业平台上的能力，现在都可以以 API、MCP 工具或 CLI 命令的形式，被 Agent 调用。 按官方拆法，它包含三块： - • Build any way you want ：60+ MCP 工具 + 30+ 预配置 coding skills，让 Claude Code、Cursor、Codex、Windsurf 这类外部 coding agent 直接连进企业组织，操作数据、流程和业务逻辑。 - • Deploy on any surface ：新的 Agentforce Experience Layer 把"做什么"和"长什么样"分开，一次定义，渲染到 Slack、Teams、ChatGPT、Claude、Gemini、移动端等多个表面。 - • Build agents you can trust at scale ：Agent Script 通用可用并开源，配合 Testing Center、Custom Scoring Evals、A/B Testing API 和可观测能力，覆盖 Agent 的全生命周期。 这些信息分开看像发布清单，放一起看会清楚很多： 重点不是放弃 UI，重点是把 UI 后面的平台能力翻出来，让 Agent 也能调用。 这是一个很现实的防守动作，也是一种进攻。 如果未来用户越来越少打开 CRM 页面，而是让 Claude、ChatGPT、企业内部 Agent 或 Slack 工作流替自己完成大部分操作，企业软件继续只守页面入口，风险会越来越大。 但如果这些 Agent 调用的还是平台里的数据、权限、流程、审计和业务逻辑，底座的位置就还在。 它拆掉的是入口垄断，守住的是运行底座。 放回国内的销售、财务、客服系统，也能看到同样的问题。一个系统最值钱的，常常不在页面，而在里面长期沉淀的客户数据、审批链路、字段口径、权限规则、历史记录，和一堆"只有这家公司才这么干"的业务习惯。 页面可以换，入口可以变。这些东西丢了，系统就只剩个壳。 但这里有一层很容易被忽略的疑问：Headless 之后，平台会不会就退化成一个"可被 Agent 查询的数据库"？ 这个担心不是没道理。如果一个系统只是把表、对象、CRUD 暴露出去，它确实容易被上层 Agent、数据中台或自建工作流绕过去，最后压成一个"存量数据源"。 这个案例想证明的，是它打开的不只是数据，还有业务动作、组织权限、流程状态、审计链路和客户上下文。 一个 Agent 友好的平台，不能只回答"这里有什么数据"，还要回答"在这个组织、这个角色、这个状态下，下一步能安全做什么"。 底座和数据库，差的就是这一句话。 ## 第一步，给 Agent 一张能看懂的说明书 过去做软件，默认调用方是人。所以很多设计都是围着人转的： - • 页面是不是清晰？ - • 按钮是不是明确？ - • 表单能不能少填？ - • 错误提示能不能让人看懂？ - • 用户能不能确认、撤回、重做？ 这些当然还重要。但 Agent 当上调用方之后，契约会多出一组很不一样的问题： - • 工具名和描述，能不能让 Agent 选对？ - • 参数 schema 是不是足够明确？ - • 哪些字段允许 Agent 推断，哪些要显式给？ - • 调用失败之后，错误能不能恢复？ - • 工具返回值，是给人看的，还是给下一步推理用的？ - • 权限、审计、计费有没有从 UI 下沉到平台？ - • Agent 为什么调用这个工具，事后能不能看见？ 也是因为这一组问题，我不太愿意把 Headless 改造简单理解成"把系统做成 API"。 API 只是技术形态。更麻烦的事，是把产品能力整理成 Agent 可理解的动作，把规则整理成 Agent 可读取的上下文，把风险整理成 Agent 不能绕过的边界。 如果契约没重写，只是把原来的页面动作粗暴包一层 MCP，体验大概率不会好。 因为 Agent 会开始猜：猜字段含义，猜流程顺序，猜错误原因，猜哪些动作可以重试，猜哪些状态算完成。人在界面里能靠经验补的上下文，Agent 未必补得上。 我自己有一个挺土的自检问题： 如果把页面拿掉，只给 Agent 一组工具和文档，它能不能知道这件事该怎么做、做到哪里算完成、错了之后怎么退回来？ 如果答得不痛快，这个产品就还没为 Agent 准备好。 顺便提一个小趋势：面向 Agent 的"文档"，已经不只是给人看的网页了。 不少平台开始同时准备几种材料： - • llms.txt ：告诉模型文档索引和入口在哪。 - • OpenAPI ：让工具和代码生成器理解接口形状。 - • skill.md ：把能力、动作、必填参数、约束和常见工作流压成 Agent 直接能读的摘要。 - • MCP Server：把真实能力暴露成可调用工具。 这件事很小，但我会继续看。过去文档更多是售后和开发者体验的一部分；Agent 时代，文档会变成产品接口的一部分。写得含糊，Agent 就含糊地调；把边界讲清楚，Agent 才有机会稳定干活。 ## 第二步，别以为工具放出来就算完 如果说前面讲的是平台怎么打开，产品这一边更该追问的是另一个问题：调用我家产品的 Agent，到底需要什么才能成功？ 这里可以把之前《 MCP 之后，CLI 又成了王？ 》里的结论借过来用一下： 别先争 CLI、API、MCP 谁更先进，先看 Agent 能不能把这件事跑完。 我自己最有体感的是 Notion 和 Slack 这两个对照组。 Notion 的 MCP 工具会 主动 告诉 Agent：要创建页面，先去拉一份 Notion 自己的 Markdown 规范，别用通用 Markdown 当默认。我让 Claude 写东西推到 Notion，几乎每次格式都是对的，表格、列表、斜体、引用，基本不出错。 Slack MCP 反过来。Agent 默认按通用 Markdown 写消息，Slack 这套自己的格式就被忽略，结果发出去的消息要么样式怪，要么我自己手动再改一遍。 例子很小，但问题说透了： 工具可用，不等于 Agent 会用。 传统 API 文档写给开发者，开发者会读、会理解、会写转换层。Agent 时代，很多调用发生在运行时。 系统得能在 Agent 需要的那一刻，把规范、schema、policy、示例直接递给它。 CLI 给了一个很朴素的样板：少交互、输出可解析、失败有明确状态、危险动作支持 --dry-run ，需要确认时能用 --yes 显式表达。把这几个要求搬到产品里，其实就是 Agent 时代的接口基本功。 所以我现在不太把 CLI 和 MCP 看成对立关系。 CLI 更像动作入口，适合本地、快速、可组合；MCP 更像治理入口，适合多团队、多租户、权限和审计更复杂的场景。 产品团队不需要押某一个名词，先把自己的能力整理到合适的入口里。 这件事讲起来像文档问题，最后会落到产品体验上。Agent 调错一次，用户体感不会停在"文档没写好"，而是"这个产品不好用"。 财务场景里也已经能看到一些早期信号。Ramp 公开的数据里有一个细节挺有意思：他们 MCP 上的周活在过去三个月翻了 10 倍，已经不是"问一问、查一查"，而是 Agent 在帮人做事，比如补字段、给交易归类、附收据、跑审批。 这里我越来越相信一件事： Agent 不会让软件被使用得更少，反而可能让它被调用得更频繁。 人一天能点多少次系统是有上限的。Agent 可以在后台跑、并行跑、跨系统跑。它会把过去因为人力不够而没发生的长尾流程重新激活：补齐字段、检查异常、生成报告、跟进审批、同步记录、触发提醒。 对软件公司来说这是好事，也是压力。SaaS 会最先感受到，因为它的商业模式本来就和使用深度、席位、自动化程度绑在一起。 好处是平台价值可能被释放出来。很多系统买了很久，被用到的能力其实少得可怜。Agent 如果能稳定调用，软件的使用深度会上去。 压力在于，旧指标和旧收费方式开始不够用了。 过去看登录人数、活跃席位、页面停留。以后还得看动作数量、流程完成率、自动化节省的时间、失败恢复成本和治理开销。 Agentforce 从按席位走向按消耗，多少也是承认了这一点：当干活的不是人是 Agent，按人头收费就站不住了。 产品团队看的指标也得跟着变。除了点击、漏斗、留存，还得看： - • Agent 为什么调用这个工具？ - • 它在哪一步卡住？ - • 哪些字段总是填错？ - • 哪类上下文总是缺失？ - • 哪些失败可以靠新增工具、参数或规则消掉？ 具体做法上，可以借鉴几个比较朴素的招：让每次工具调用带上一个 rationale （调用理由）、单独提供一个 feedback 工具、在工具里设计专门捕捉上下文的参数。 我觉得这事重要，是因为 Agent 的反馈往往比人更具体。人可能只丢一句"不好用"，Agent 会留下结构化的失败路径：我想做什么、试了什么、缺了哪个参数、哪个返回值不够。这些信号如果能进产品路线，Agent 反过来会帮产品团队看到新的功能边界。 有点像早年做埋点。一开始大家只看 PV、UV、按钮点击，后来才慢慢意识到：更有用的是用户在哪一步放弃、哪里反复重试、哪个状态转不下去。 Agent 时代也一样，只是这次留下的是一串工具调用、失败原因和上下文缺口。 ## 第三步，真进生产，就绕不开确定性 这个案例里我最关注的是 Agent Script。React 支持和 MCP 数量都重要，但它们没有把生产里的难题说透。 官方对它的定位说得很直白：把自然语言指令的灵活性，和程序化表达式处理业务规则的可靠性结合起来。一个可读、可版本化、可审计的 flat file，里面有 if/else、状态转移、变量、动作顺序，以及子 Agent 和动作选择。 它解决的是一个特别现实的问题： 企业不能只靠提示词把 Agent 放进生产。 原型阶段 Agent 看着挺聪明：给它工具、给它上下文，能跑出 demo。但上线之后问题会变得很具体： - • 改一句提示词，会不会影响原来跑通的流程？ - • 客服 Agent 在什么条件下要走固定政策？ - • 哪些步骤可以让模型自由推理，哪些步骤要按业务规则执行？ - • 失败之后能不能回放？ - • 新版本能不能和旧版本做 A/B？ - • 最后是谁批准了这个动作？ VentureBeat 那篇报道里有个细节我读得心里一紧：早期 Agentforce 客户把 Agent 做进生产之后，反而不敢改了，因为系统太脆。动一点就不知道会不会还稳，所有测试都得重做。 很多团队第一次把 Agent 接进流程，最开始兴奋的是"它终于能干活了"。过一阵头疼的，往往是"我不敢改它了"。 这个问题不只属于某一家公司。只要 Agent 进了财务、客服、销售、法务、IT 运维，就都会撞上同一个矛盾： 模型本身是概率系统，但企业流程要求可解释、可回放、可验证。 Agent Script 的价值，不在于它能不能替代代码。它更像是在承认一件事： Agent 的自由推理和企业的确定性流程之间，需要一个中间层。 这个中间层得能表达状态、条件、动作和边界，让模型在某些节点自由决定，也让业务规则在另一些节点强制执行。 这和我们之前聊 Harness 的思路是一致的：模型越强，外面的系统越重要。最后能不能交付，不能只看模型会不会答，还得看主循环、工具、上下文、权限、状态、验证和回滚能不能一起工作。 ## 第四步，先分清它面对谁 采访里还有一个有趣的划分：客户面对的 Agent，和员工自己用的 Agent，需要不同的控制强度。 面向客户的 Agent ，比如客服、咨询、售后，通常需要更强的确定性。它要遵守品牌规则、合规边界、政策限制和业务流程，很多时候不能自由探索。更合适的结构是相对静态的流程图：确认身份、识别意图、收集信息、调用工具、返回结果，必要时转人工。 员工自己用的 Agent ，比如 coding agent、销售研究 Agent、市场素材生成，可以放得更开。员工本身是专家，会检查输出、决定能不能发出去。这种场景里，Agent 可以动态展开任务路径，失败了换一条，发现新线索再继续搜。 我倾向把它们理解成两种运行模式： 场景 更适合的结构 主要约束 人的角色 客户面对的 Agent 静态流程图 合规、品牌、确定性、可审计 兜底和审批 员工使用的 Agent 动态任务图 效率、探索、工具覆盖、上下文质量 审阅和决策 这张表不是给所有 Agent 贴标签，更像是提醒： 别把一种形态套到所有场景上。 很多 Agent 产品爱犯这个错：把"能自由推理"当成所有场景的优点。 但在客户服务、财务审批、医疗保险、法务流程里，自由推理本身就可能是风险。反过来，在员工研究、代码生成、资料整理、方案探索里，过强的静态流程又会把 Agent 绑死。 我更愿意细看的是另一件事：让这两类模式跑在同一个底座上。一个偏静态，一个偏动态， 但数据、权限、工具、观测和治理层尽量复用。采访里那句"It's all a graph underneath"基本就是这个意思。 这对企业架构很关键。否则每做一个 Agent 场景，就搭一个割裂系统，后面权限、审计、计费、运维都会变成长期负担。 ## 第五步，把它放回产品架构里看 把这个案例、产品侧的早期实践，以及之前我们聊过的 Harness、Skills、过程资产放一起看，我会把"Agent 友好的产品"先拆成五层。这里的产品不限于企业软件，但企业软件会是压力最大的那一类。 Agent 友好的产品五层栈 第一层，表面层。 用户不一定在你的产品页面里。他可能在 Slack、Teams、ChatGPT、Claude、移动端，或者企业自己的工作台里。产品要接受一个现实：入口会分散。 第二层，调用层。 Agent 通过 API、CLI、MCP、Hosted Server 或 Tool Registry 进入系统。这里先解决几个很实在的问题：接口稳不稳定、能不能被发现、鉴权和限流够不够。之前聊 CLI 时说的 --help 、 --json 、exit code，也属于这一层，只是它们更贴近开发者工具。 第三层，语义层。 这是现在很多产品最薄弱的一层。工具描述、schema、policy、错误契约、示例都在这里。它们决定 Agent 是少猜，还是一路猜。很多时候，问题不在 Agent 能力，而在产品给它的语义太粗。 第四层，业务底座。 这是产品多年攒下来的部分：数据、流程、业务逻辑、集成关系、历史记录、团队经验、过程资产。企业软件在这里尤其重，因为它背后常常连着组织的真实运转方式。 第五层，治理层。 认证、授权、审计、测试、评估、观测、回滚、计费都收在这里。Agent 能做的事越多，这层越不能靠临时补丁。 五层里我最担心的是 第三层和第五层。 很多团队会先做第二层：发 API、接 MCP、写插件。这当然要做，但如果没有语义层，Agent 还是会猜；没有治理层，企业也不敢让它真做事。 所以我更愿意把"Agent 友好"理解成产品架构能力，而不是一个新入口。 只加入口、不补语义和治理，最后大概率会变成"看起来接入了 Agent，实际不敢让它做关键动作"。 ## 动手之前 不写口号，尽量说具体一点。 一，先把高频能力拆成原子动作。 旧系统里很多能力藏在页面里。一个按钮背后可能有权限校验、字段检查、状态流转、通知、审计和外部系统同步。人点按钮时，这些复杂性都被 UI 包住了。Agent 调用时不能只丢一个粗接口给它，得说清楚：这个动作能做什么、不能做什么、前置条件是什么、失败能不能重试、成功后有什么副作用。这一步做不好，再好的 MCP 包装也只是壳。 如果这个动作先做成 CLI，也别只按人类习惯写。至少要有 --help 、 --json 、稳定 exit code、 --dry-run 和非交互模式。很多时候，CLI 是产品能力被 Agent 调用之前最便宜的试验场。 二，把权限和审计从 UI 下沉到平台。 如果安全只在前端页面，Agent 一接入就出事。Hosted MCP 这类设计反复强调所有调用要遵守组织安全模型，包括对象和字段级安全、共享规则和 profile。方向是对的：Agent 调用工具时要继承同样的权限，所有动作都要可追踪。否则企业不会真放手。 三，给 Agent 一条明确的成功路径。 工具描述、schema、policy、示例、错误返回，都要面向 Agent 重新设计。可以借鉴 Notion 的做法：复杂规范别全塞进工具描述里，给一个可以按需读取的资源。工具描述讲边界，资源讲细节。一句话，别让 Agent 在生产流程里靠猜。 四，把反馈循环做进产品。 让工具调用带上 rationale，让 Agent 在卡住的时候有地方提交结构化反馈。这一步主要是为了看清真实工作流。用户到底想完成什么？哪一步最常失败？哪个工具缺一个参数就能少很多绕路？这些问题会比"按钮点击率"更接近 Agent 时代的产品改进。 五，上线前能测试，上线后能观测。 企业 Agent 的发布流程不能停在 demo。 更稳的链路通常包括：离线测试、自定义评分、A/B Testing、调用链观测、失败回放、版本回滚。这些东西看起来像配套工具，实际上会变成企业 Agent 的基础设施。这一层不够，Agent 越能干，团队越紧张。 ## 最后 我不太相信 "AI 会杀死所有 SaaS" 这种说法。 软件里难的部分，一直不只在界面，也不只在代码。越靠近业务，越难的是长期沉淀的数据、组织权限、业务流程、审计要求、集成关系和交付责任。 Agent 会让很多旧界面变得不那么重要，也会让一批靠低价值录入和流程摩擦撑起来的产品失去空间。 但它同时会放大平台型软件的价值。前提是这个平台愿意把自己打开，让 Agent 能用；也愿意把自己管住，让 Agent 用得可控。 Salesforce Headless 360 这类动作会被反复拿出来看，原因就在这里：它争夺的是 Agent 时代的运行底座，旧 SaaS 的页面入口反而退到了后面。 对更多软件公司来说，问题可以换一种问法： 如果明天你的用户不再频繁打开你的产品页面，而是让自己的 Agent 来调用你的系统，这个系统还能不能被正确理解、稳定执行、清楚计费、完整审计？ 能认真回答这个问题的产品，才算开始为 Agent 时代做准备。 我自己的直觉是，这事不会一夜发生。很多企业系统会继续保留页面，很多人也会继续登录后台。只是越来越多的低频、重复、跨系统动作，会先被 Agent 接走。 等到那一天再回头看，软件的竞争点可能就不再是"页面做得多顺"，而是： 这个系统有没有把自己的业务能力讲清楚、管得住，也交得出去。 ## 相关推文 - • 《 把 AI 当成新同事：面向架构师的 Agent 编码工程化方法 》 - • 《 Agent Harness 综述：同一个模型，为什么做出来的 Agent 差这么远 》 - • 《 MCP 退潮后，CLI 又成了王？一套更务实的判断框架 》 - • 《 再看 Hermes Skills：Agent 如何自我进化？ 》 - • 《 Claude Code 长任务为什么不容易跑偏：从压缩、记忆到续写的 Runtime 设计 》 ## 参考资料 - • Salesforce 官方公告：Introducing Salesforce Headless 360. No Browser Required. https://www.salesforce.com/news/stories/salesforce-headless-360-announcement/ - • VentureBeat：Salesforce launches Headless 360 to turn its entire platform into infrastructure for AI agents https://venturebeat.com/ai/salesforce-launches-headless-360-to-turn-its-entire-platform-into-infrastructure-for-ai-agents - • Salesforce Developers：New in Salesforce Developer Edition: Agentforce Vibes IDE, Claude 4.5, MCP https://developer.salesforce.com/blogs/2026/04/new-developer-edition-agentforce-vibes-claude-mcp - • Salesforce Developers：Build with React, Run on Salesforce: Introducing Salesforce Multi-Framework https://developer.salesforce.com/blogs/2026/04/build-with-react-run-on-salesforce-introducing-salesforce-multi-framework - • Salesforce Developers：Get Started with Agent Script https://developer.salesforce.com/docs/ai/agentforce/guide/agent-script.html - • Salesforce GitHub：salesforce/agentscript https://github.com/salesforce/agentscript - • Salesforce：Agentforce Pricing https://www.salesforce.com/agentforce/pricing/ - • Ramp：How Finance Teams Are Using Ramp's MCP & CLI for Month-End https://ramp.com/blog/ramp-customers-are-running-month-end-with-ai-assistants - • Teddy Riker：Designing for Agents https://x.com/teddy_riker/status/2047312986696454584 如喜欢本文，请点击右上角，把文章分享到朋友圈 如有想了解学习的技术点，请留言给若飞安排分享 因公众号更改推送规则，请点“在看”并加“星标”第一时间获取精彩技术分享 ·END· ```python 相关阅读： - 刚刚，Claude Code“代码泄露”背后：如何重新看 Agent Harness - 大家都在讲 Harness，但它到底该怎么理解 - 模型越来越强，为什么大家却开始重写 Harness - 如何让单个 Agent 做长任务不失真：Anthropic 给出了一套更工程化的答案 - Claude Code高手的 8 个 Claude Code 实战习惯 - 别从 README 开始：一个架构师会怎样翻 Codex 仓库 - Spec 不是代码的替代品，它是 AI Coding 的上下文管理层 - 如何让 Agents 自己设计、升级 Agents - OpenAI怎么把开源项目维护做成工作流：Skills、AGENTS.md 和 CI 的一套组合拳 - Claude Skills 入门：把“会用 AI”变成“可复制的工程能力” - 一套可复制的 Claude Code 配置方案：CLAUDE.md、Rules、Commands、Hooks - Claude Code 最佳实践：把上下文变成生产力（团队可落地版） - 把 AI 当成新同事：Agent Coding 的上下文与验证体系 - 一周写百万行的背后：Cursor长时间运行 Agent 的工程方法论 - 2026年生活重启指南 - 我真不敢相信，AI 先加速的是工程师。 - 扒一扒 Claude Cowork 系统提示词：Anthropic 如何打造数字同事 - Cowork 安全架构深度解析：从 Claude Code 到 Cowork，Anthropic 如何把“可控”做成产品 - Anthropic官方万字长文：AI Agent评估的系统化方法论 - 银弹还是枷锁？Claude Agent SDK 的架构真相 - Claude Code创始人亲授13条使用技巧 - Claude Code 内部工具开源 code-simplifier：终结 AI 屎山代码的终极方案 ``` 版权申明：内容来源网络，仅供学习研究，版权归原创者所有。如有侵权烦请告知，我们会立即删除并表示歉意。谢谢! 架构师 我们都是架构师！