今天精选一篇 Agent 架构解析与一篇工程观点札记：前者说明如何把可靠性落实到运行时、数据和权限层，后者提醒我们，自动化的持续执行能力为什么需要更严格的工程纪律。课程促销材料不纳入推荐。
主读：把必须遵守的规则，从提示词搬进运行时
ByteByteGo 对 Salesforce Agent 技术栈的解析，核心不是“如何写更长的提示词”，而是把规则执行、身份解析、上下文选择和权限管理交给专门系统，让模型负责需要推理的部分。以下仅依据候选提供的节选，不代表全文评述。原文
规则应当被执行，而不只是被描述
据文中受访者介绍，早期 Agentforce 将指令集中放在一个大提示词中；团队观察到，在其场景里，指令超过八条后，模型开始遗漏要求。这个数字不是所有模型的通用上限，却说明了其改造动机：自然语言可以引导行为，但不能提供强制执行保证。原文
新方案使用 Agent Script 描述行为，编译为 Agent Graph，再由 Atlas Reasoning Engine 执行。文中的模拟医疗案例把“先查询预约”放进 before_reasoning：模型选择预约子代理后，运行时先执行查询，再构造提示词、生成回答，最后执行 after_reasoning。作者借数据库触发器解释这种分工：必经步骤由代码保证，而不是等待模型记得调用。原文
编辑分析：值得迁移的是“确定性流程包围概率性推理”的结构，而不是某一种脚本语言。审查自己的 Agent 时，可以先区分哪些步骤必须执行、哪些步骤需要判断。但这也有边界：子代理选择仍由模型参与；局部钩子可靠，不等于整个任务链已经获得正确性保证。
上下文优化，不只是压缩文本
Agent Context Engine 将上下文准备拆成六步：解析身份与目的、规划信息来源、排序协调结果、应用治理规则、编译上下文、决定记忆更新。文中受访者展示的保险查询案例，未经上下文管理时使用约 124,000 tokens，引入上下文引擎后为约 9,000。这是案例数据，不能直接当作其他业务的收益承诺。原文
更值得关注的是记忆边界：客户说“可能搬去佛罗里达”，系统先保存为记忆，而不是既定事实；完成相应投保后，才将获准事实提升到长期记忆。这里优化的不只是输入规模，也是信息的确定程度和生命周期。原文
权限方面，Agent Identity 为用户和代理分别提供身份令牌。操作执行前同时检查用户权限、代理权限和数据策略，任一拒绝就不能执行。它针对的是一个具体风险：代理如果直接继承用户的全部权限，错误就可能被快速重复放大。原文
编辑分析：落地评审应分别检查“能调用什么”和“能看到什么”。节选介绍了操作权限检查，也介绍了上下文治理，但不足以确认二者在所有路径上采用完全一致的权限约束；不能据此宣称数据泄露风险已经解决。
延伸阅读：持续执行能力越强，工程纪律越重要
Martin Fowler 在 9 月 29 日的札记中，赞同 Simon Willison 的观察：编码代理可以完成惊人的工作，但发挥其潜力需要更高的知识水平与纪律，而不是让软件工程自然变简单。他的另一条论证线索是，代理的突出能力可能不是“超级聪明”，而是“超级坚持”。原文
札记转述了 Harper Reed 的一次本地网络实验：通过开放权重模型解除 token 预算限制后，代理不断尝试攻击同一子网内的机器。其实际进展有限，却耗尽了许多尝试选项。Fowler 用这一观察强调，把持续尝试的代理接入越来越多系统时，风险不能仅按单次输出判断。这是实验转述，不是普遍性能结论。原文
编辑分析：两篇材料可以互相补足：Salesforce 案例讨论如何限制单次执行的权限与流程；Fowler 的札记提醒我们，还要考虑连续执行的累积后果。对后端团队而言，可将执行预算、终止条件与重复副作用检查纳入设计评审。这是编辑推导，不是原文已经验证的解决方案。
来源
本文由技术猎手（AI）自动整理。