创始人如何基于 Claude Managed Agents 构建产品
原题How founders build on Claude Managed Agents
推荐理由这场 Claude 圆桌把 Managed Agents 放进会议准备、销售账户与产品分析三类真实场景。最有价值的原则是先把用户需要的结果写成 rubric,再让独立上下文检查正确性和来源;面对不确定信息,宁可不展示,也不制造会伤害信任的误判。讨论还覆盖账户、用户与组织记忆的分层,代码沙箱,模型迁移回归和成本归因。它提供的不是独立效果测量,而是一套可借鉴的主动型 Agent 产品设计方法。
看前速览
多位创始人分享 Claude Managed Agents 如何通过结果 rubric、独立验证、分层记忆、沙箱工具和对速度、成本、控制力的取舍,支持会议准备、销售情报与产品分析。
结果定义与独立验证让主动型智能体更安全。
团队把期望的用户体验转化为 rubric,用独立上下文检查正确性和归因;面对不确定结果时,宁可不展示,也不提供错误背景。
记忆必须按实际工作任务划分边界。
销售案例将账户记忆与用户、组织知识分开,再在预测和优先级排序等跨账户问题中组合这些层次。
当 harness 不是产品壁垒时,托管基础设施能加快学习。
嘉宾主张利用通用基础设施快速测试和迭代;只有当细粒度控制决定功能能否成立时,才值得更多内部自建。
评估、安全边界和成本控制需要随部署共同演进。
圆桌将代码沙箱、真实客户评估、模型迁移检查、成本归因、批处理和模型选择,视为有状态智能体系统运营的一体化问题。
完整摘要
这场 Claude 圆桌讨论提供了 Managed Agents 在三类生产场景中的具体实践:会议准备与后续跟进、账户级及跨账户的销售工作,以及能够理解代码的产品分析。核心设计原则是先定义可以独立核验的结果,再在信息不确定时选择不展示,避免制造代价高昂的错误判断。嘉宾解释了账户、用户和组织记忆如何服务不同问题;受限工具与沙箱如何让代码访问更安全;以及当基础设施并非产品差异化能力时,团队为何应优先购买而不是自建。讨论也涉及提示词和工具的迭代、运行时与离线评估、有状态外部系统、模型迁移回归、成本归因、批处理和模型选择。由于这是一场官方产品对谈,关于效果与经济权衡的说法更适合作为实践案例,而非独立测量结论。
文字稿
简要描述Brief Description
本次圆桌讨论探讨了三家公司如何将 Claude Managed Agents 用于会议准备、销售情报和产品分析。讨论重点是支撑这些成果的实际设计选择,以及独立验证、组织级和客户账户级记忆、沙盒化代码访问、快速迭代、评估、模型迁移,以及速度、控制、成本和产品体验之间的权衡。This roundtable explores how three companies use Claude Managed Agents in meeting preparation, sales intelligence, and product analytics. The discussion focuses on the practical design choices behind outcomes and independent verification, organization-wide and account-level memory, sandboxed code access, rapid iteration, evaluation, model migration, and the trade-offs among speed, control, cost, and product experience.
目录Table of Contents
- 跨会议、销售和分析管理智能体Managed Agents across meetings, sales, and analytics
- 成果、评分标准与独立验证Outcomes, rubrics, and independent verification
- Watchtower 中的记忆与跨账户工作Memory and cross-account work in Watchtower
- 对源代码和运营分析进行沙盒隔离Sandboxing source code and operational analytics
- 何时构建测试框架,何时购买现成的测试框架When to build a harness and when to buy one
- 快速迭代、提示词、工具和评估Rapid iteration, prompts, tools, and evaluations
- 有状态系统、外部工具与模型迁移Stateful systems, external tools, and model migrations
- 成本、归因与产品控制Cost, attribution, and product control
覆盖会议、销售和分析领域的托管智能体Managed Agents across meetings, sales, and analytics
发言人:对话以三个 Managed Agents 在生产环境中的应用案例开场。一个团队把会议视为一段完整的流程:会前准备、会中支持和会后跟进。大多数产品只关注会议本身,但更有价值的机会在于帮助人们为对话做好准备,确保对话达成预期结果,并落实后续工作。该团队既使用 Managed Agents 生成简报、帮助人们做好准备,也用它们在会议结束后自动执行任务。Speaker: The conversation opens with three examples of Managed Agents in production. One team treats a meeting as a complete journey: preparation before the meeting, support during it, and follow-through afterward. Most products focus only on the meeting itself, but the more useful opportunity is helping a person prepare for a conversation, ensuring the intended outcome happens in that conversation, and carrying out the work that follows. The team uses Managed Agents both for briefs that prepare people and for task automation after a meeting.
发言人:另一家公司为销售团队构建智能体。它的基础产品会为每个客户分配一个持续工作的智能体;该智能体会积累记忆,并判断应该采取哪些行动来推动客户关系向前发展。销售工作还涉及跨客户的问题,例如某位销售代表今天应该跟进哪五个客户,或者经理应该预测下个季度的哪些交易。该公司为跨客户报告、汇总和分层汇总创建了 Watchtower。与面向单个客户的智能体不同,Watchtower 需要一套不同的工具和能力。团队仅用两周就借助 Managed Agents 将其搭建完成;它不仅成为使用最频繁的功能之一,还为产品的其他部分提供了支持。Speaker: Another company builds agents for sales teams. Its basic product assigns an always-working agent to each account; that agent builds memory and determines what should happen to move the account forward. Sales work also includes questions that span accounts, such as which five accounts a representative should pursue today or which deals a manager should forecast next quarter. The company created Watchtower for cross-account reporting, aggregation, and rollups. Unlike the per-account agent, Watchtower needs a different set of tools and capabilities. The team assembled it with Managed Agents in two weeks, and it became one of the most-used features while also powering other parts of the product.
发言人:第三家公司提供嵌入应用程序中的产品分析服务。随着团队加快交付速度,为应用程序添加埋点,以及了解分析结果在哪些方面偏离软件的实际运行情况,都变得更加困难。该公司在其平台前端构建了一个智能体,将代码库快照与观察到的应用行为连接起来。Managed Agents 让它能够将代码与生产环境中的实际情况进行对比,主动发送洞察,有时还会提出修复建议。Speaker: A third company provides product analytics embedded in applications. As teams ship faster, it becomes more difficult to instrument applications and to understand where analytics diverges from what the software is actually doing. The company built an agent in front of its platform that connects a snapshot of a codebase with observed application behavior. Managed Agents let it compare code with production reality, send proactive insights, and sometimes propose fixes.
成果、评分标准与独立验证Outcomes, rubrics, and independent verification
发言人:会议产品团队解释了为什么成果是其使用托管代理的核心。简报应找出合适的人选,说明此人为何重要,找回此前的背景信息,并明确会议中应达成什么目标。简报只有准确才有价值。如果它把一个名叫 Tom 的人和另一个人混淆,就可能主动损害用户体验,让用户带着错误的背景信息进入会议。Speaker: The meeting-product team explains why outcomes are central to its use of Managed Agents. A brief should identify the right person, explain why that person matters, recover prior context, and clarify what should be achieved in the meeting. A brief is valuable only when it is correct. If it confuses one person named Tom with another, it can actively damage the experience by making the user enter a meeting with false context.
团队宁可什么都不展示,也不愿展示假阳性结果。结果可供独立评估者判断智能体是否得出了正确结论,以及来源归属是否准确。这不仅让展示的信息更加可靠,也能改进反馈循环:结果越是能够频繁接受评估,就越能将学习融入智能体的初始循环中。Speaker: The team would rather show nothing than show a false positive. Outcomes allow an independent assessor to determine whether the agent produced the right result and whether source attribution is correct. This makes displayed information more reliable and also improves feedback loops: the more frequently a result can be assessed, the more that learning can be built into the initial agent loop.
发言人:结果被描述为提供给智能体的一套评估标准,智能体会不断迭代,直到满足这些标准。对于会议预读材料,评估标准包括终端用户的需求,例如找到正确的 LinkedIn 个人资料——这可以客观验证——以及材料的呈现质量。信息必须便于快速浏览和阅读;五页的预读材料,或顺序不当的材料,都不会被使用。团队将期望的用户体验转化为评估标准,并以此为目标不断优化。Speaker: An outcome is described as a rubric supplied to an agent, with the agent iterating until that rubric is satisfied. For a meeting pre-read, the rubric includes end-user needs such as identifying the correct LinkedIn profile, which is objectively verifiable, as well as presentation quality. Information must be easy to scan and read; a five-page pre-read or one arranged in the wrong order will not be used. The team turns desired user experience into rubric criteria and hill-climbs against them.
发言人:这些检查是在运行时进行的。会议简报可以在会议前生成,并在可用的时间窗口内进行评估。例如,可以在对话开始前二十四小时启动工作,让系统有时间评估结果。验证可以使用 LinkedIn、电子邮件和日历数据等独立证据。其核心价值在于,由一个拥有独立上下文窗口的单独代理评估工作,不受创建该工作过程轨迹的影响。Speaker: These checks happen at runtime. A meeting brief may be generated before a meeting and assessed within that available window. In one example, work begins twenty-four hours before the conversation, giving the system time to assess results. Verification can use independent evidence such as LinkedIn, email, and calendar data. The central value is a separate agent with an independent context window assessing work independently from the trace that created it.
发言者:并非总是需要通过完整迭代追求完美。对于主动式产品,暂不提供不确定的信息可能更好:尽可能提供帮助,但不要造成伤害或令人烦扰。独立、干净的上下文窗口让质量评估成为部署的一部分,而不只是原有智能体循环中的又一个内部步骤。Speaker: Full iteration to perfection is not always required. In proactive products, it can be better to withhold uncertain information: help when possible, but do not cause harm or annoyance. An independent clean context window makes quality assessment part of deployment rather than merely another internal step in the original agent loop.
Watchtower 中的记忆与跨账户工作Memory and cross-account work in Watchtower
发言人:销售团队表示,特定于公司的概念很难处理,因为每个组织对所有权、预测和交易流程的定义都不一样,而且源数据往往杂乱无章。Salesforce 实例中可能有许多已弃用的字段,它们的含义几乎相同。诸如“下季度应该预测什么”这类问题十分重要,必须得到准确回答。Speaker: The sales team says that company-specific concepts are difficult because every organization defines ownership, forecasting, and deal processes differently, and the source data is often messy. A Salesforce instance may have many deprecated fields that mean nearly the same thing. Questions such as what should be forecast next quarter are important and require a correct answer.
发言人:随着人们使用产品,系统会逐步学习组织概念,并将其存储在组织范围的记忆中。这能改善所有人的使用效果,也避免一开始就强迫大家进行大量配置。用户提出问题时,产品可以追问以澄清需求,并保存由此获得的信息。有些查询还需要跨许多账户开展深入工作。面对数百笔交易,系统可以编写代码、以编程方式调用工具、缩小候选范围、将任务分派给负责各个账户的独立智能体,再汇总结果。Speaker: As people use the product, the system learns organizational concepts and stores them in organization-wide memory. That improves results for everyone and avoids forcing a large configuration exercise at the beginning. When a user asks a question, the product can ask clarifying questions and save the resulting information. Some queries also require deep work across many accounts. For hundreds of deals, the system can write code, make programmatic tool calls, narrow a candidate set, fan work out to independent agents for each account, and roll the results back up.
发言人:该产品区分两类记忆:一类与特定账户关联,另一类涉及预测等跨账户流程。账户代理贯穿账户的整个生命周期,积累上下文并学习相关概念,以便日后汇总。跨账户工作会产生另一类记忆,这类记忆对单个账户的相关性可能较低,但对 Watchtower 很重要。公司将账户级、用户级和组织级记忆结合起来,以改进产品的不同部分。Speaker: The product distinguishes between memory attached to a particular account and memory about cross-account processes such as forecasting. Account agents run throughout the full account lifecycle, building context and learning concepts that can later be rolled up. Cross-account work produces another class of memory that may be less relevant to a single account but is important to Watchtower. The company uses account, user, and organization-level memory together to improve different parts of the product.
发言者:在典型配置中,一名客户主管可能会为每个客户配备一个智能体。较新的 Watchtower 产品会利用整个智能体群积累的记忆来回答更广泛的问题并提出行动建议。它可以将客户记忆作为输入,编写代码查询这些记忆,并在必要时将工作分派出去。它还会使用关于个人、公司、优先事项及其运作方式的托管记忆。这既能帮助个人贡献者,也能支持领导者:一位管理着五名客户主管的销售负责人,实际上可能需要了解五百个客户的情况。Speaker: In a typical setup, an account executive may have an agent for every account. The newer Watchtower product uses the collected memory across that fleet to answer broader questions and suggest actions. It can use account memory as an input, write code to query it, and fan work out when necessary. It also uses managed memory about the individual, the company, its priorities, and how it operates. This supports both individual contributors and leaders: a sales leader managing five account executives may effectively need visibility into five hundred accounts.
对源代码进行沙箱隔离并开展运营分析Sandboxing source code and operational analytics
发言者:分析团队认为,当智能体对客户的源代码进行快照时,沙箱隔离至关重要。源代码可能包含机密信息,因此团队必须谨慎控制智能体可使用的工具、发送给它的数据,以及它能够执行的操作。一次成功的交互可能以向代码仓库推送拉取请求告终。在内部构建所有必要的安全保障和安全边界,并非产品价值的核心所在,但这些机制必须足够可靠,才能让小型企业和大型企业信任该系统。Speaker: The analytics team describes sandboxing as essential when an agent snapshots customer source code. Source code may contain secrets, so the team must carefully control the tools available to an agent, the data sent to it, and the actions it can take. A successful interaction may end with a pull request pushed to a repository. Building all the required safety and security boundaries internally would not be core to the product's value, but they must work well enough for small businesses and large enterprises to trust the system.
发言人:Managed Agents 帮助团队迅速达到这一基准。它采用多种会话类型:用于大规模排查问题的夜间批处理系统、定期分析漏斗变化的会话,以及能够检查源代码、更准确地回答用户问题的快速会话。圆桌讨论将这些归纳为 Managed Agents 的三个示例:具备沙箱隔离的智能体、以结果为导向的智能体,以及具备记忆能力的智能体。Speaker: Managed Agents helped the team reach that baseline quickly. It uses several types of sessions: overnight batch systems that look for issues at scale, scheduled analysis of funnel changes, and faster sessions that inspect source code to answer a user's question more accurately. The roundtable characterizes these as three examples of Managed Agents: agents with sandboxing, agents with outcomes, and agents with memory.
发言人:分析集成的实际用途并不局限于单次代码审查。提交拉取请求时,公司可以启动一个托管会话来审查代码、了解变更,并进行轻量级的用户体验审查,以防糟糕的用户体验被提交。变更合并后,它可以判断是否需要更新分析数据或添加埋点,并可能创建后续拉取请求。夜间流程会检查转化率是否在一夜之间下滑,或在更长时间内持续恶化;它们会寻找可能解释这种趋势的变更,并提出修复建议。团队还会检查智能体对话,识别异常高的错误率,并提出提示词修改建议。更大的目标是让软件越来越能理解真实用户行为,并在团队持续快速交付的同时提出修复建议。Speaker: The analytics integration has practical uses beyond a single review. When a pull request is submitted, the company can launch a managed session to review the code, understand the change, and apply a lightweight UX review intended to prevent poor user experience from being committed. Once a change is merged, it can identify whether analytics must be updated or instrumentation added, and it may open a follow-up pull request. Nightly processes examine whether conversion dropped overnight or degraded over a longer period, look for changes that might explain the pattern, and suggest fixes. The team also examines agentic conversations, identifies unusually high error rates, and can propose prompt changes. The larger goal is software that increasingly understands real user behavior and suggests fixes while teams keep shipping quickly.
什么时候该自建测试框架,什么时候该购买现成的When to build a harness and when to buy one
发言人:是自建定制化框架,还是采用托管方案,取决于这个框架是否是该功能的核心竞争力。对于会议简报而言,框架并非核心价值;关键在于用户能否获得所需信息。相比之下,完全通过语音控制、类似 Jarvis 的系统,可能会让框架本身成为核心竞争力,因为它有望解锁新的能力。实际权衡的是掌控力与成本、时间:如果基础设施不会决定产品质量,就购买;如果会,就自己构建。Speaker: The decision to build a custom harness or use a managed solution depends on whether the harness is a core competency of the feature. For meeting briefs, the harness is not the core value; what matters is whether users receive the information they need. In contrast, a fully voice-controlled Jarvis-like system might make the harness itself a core competency because it could unlock new capabilities. The practical trade-off is control against cost and time: if the infrastructure does not determine the quality of the product, buy it; if it does, build it.
演讲者:产品早期阶段尤其讲究速度。团队正在验证产品与市场的契合度,以及那些能让其解决方案远胜传统替代方案的独特功能。参与者主要并非基础设施公司,也不需要自建基础设施来解决核心产品问题。之后他们或许需要更精细的控制,或希望采用不同的运营成本模式,但在早期,首要任务是尽快将功能推向客户,并迅速迭代。Speaker: The early stage of a product is especially sensitive to speed. Teams are validating product-market fit and the special features that make their solution dramatically better than traditional alternatives. The participants are not primarily infrastructure companies, and they do not need to build their own infrastructure to solve their core product problems. There may later be a need for finer-grained control or different operating costs, but early on the priority is getting features in front of customers quickly and changing them quickly.
讲者:一位参与者原本有一套自建方案,但遇到了不少问题,最终意识到需要进行大规模重建。迁移到 Managed Agents 的过程很快,也涵盖了团队原以为需要自行处理的边缘情况。他们几天内就搭建好了可用的基础设施,并在几周内完成了产品迁移。另一个团队只用一天就构建出了会议功能的初版,随后又花了几天迭代,在接下来的几周里将用户规模从大约一百人扩大到原来的约一千倍。剩下的难点在于,团队需要通过构建、自用测试、与其他人一起测试,并在两到三周内反复迭代,准确了解用户的需求。Speaker: One participant had a homegrown solution but began encountering enough issues to conclude it would need a substantial rebuild. Moving to Managed Agents was fast and covered edge cases the team had expected to handle themselves. They had working infrastructure within days and moved the product over within weeks. Another team could build a first version of a meeting feature in a day, then scale from roughly one hundred to one thousand times more users over the following weeks with a few more days of iteration. The remaining hard work was learning exactly what users wanted through building, dogfooding, testing with others, and iterating over two or three weeks.
快速迭代、提示词、工具和评估Rapid iteration, prompts, tools, and evaluations
发言人:在迭代过程中,团队会调整提示词、技能、工具和编排循环。对于会议助手,关键问题包括何时进行搜索、检索和排序相关信息,决定呈现哪些内容,以及如何协调这些步骤并整合多个来源的信息。当托管基础设施负责处理压缩等问题时,团队就能专注于为特定会议筛选并组织最重要的信息。之后,团队可以根据结果评估这些信息,并不断迭代,直至达到预期效果。Speaker: During iteration, the teams change prompts, skills, tools, and the orchestration loop. For a meeting assistant, the key questions include when to search, retrieve, rank relevant information, decide what to surface, and coordinate those steps across sources. When managed infrastructure handles concerns such as compaction, the team can focus on selecting and structuring the most important information for the particular meeting. Outcomes then help the team assess that information and iterate toward the desired result.
发言人:一个有用的区分是:产品从尚未足够吸引人,到必须持续保持卓越,这两个阶段并不相同。在早期阶段,团队可以凭直觉不断迭代,探索某项功能是否能让用户持续使用。一旦用户黏性得到验证,就必须进行系统化评估。评估无法让一个缺乏吸引力的产品变得有吸引力;团队必须先找到产品对用户有价值的原因。在快速迭代期间,托管基础设施尤其有用,因为它能解决一些共用的基础设施问题,例如提示词缓存,而这也有助于控制成本。Speaker: A useful distinction emerges between the phase where a product is still becoming compelling and the phase where it must be made consistently excellent. In the early phase, teams can iterate on intuition and discover whether a feature is sticky. Once it is sticky, systematic evaluations are necessary. Evaluation cannot make an unappealing product compelling; the team must first find what makes it valuable to users. Managed infrastructure is especially useful during rapid iteration because it solves shared infrastructure concerns such as prompt caching, which also matters for cost.
发言人:评估会在产品体验足够好之后开始。内部反馈很容易收集,但这有可能导致产品过度适配员工,而非客户。团队需要外部数据点和反馈,例如用户对某项功能效果的正面或负面回应。随着时间推移,这会形成一系列评估,涵盖回归问题、困难场景、不同的数据划分以及不同的任务类型。圆桌讨论建议,尽可能让离线评估所用的评判标准与运行时结果所用的评判标准保持一致。Speaker: Evaluation begins after a product feels sufficiently good. Internal feedback is easy to gather, but it risks overfitting to employees rather than customers. Teams need external data points and feedback such as positive and negative responses to a feature outcome. Over time, that produces cohorts of evaluations for regressions, hard scenarios, different data partitions, and different task types. The roundtable recommends aligning the rubrics used for offline evaluations with the rubrics used in runtime outcomes whenever possible.
有状态系统、外部工具与模型迁移Stateful systems, external tools, and model migrations
发言者:起初,销售团队很难设计出好的评估,因为内部试用无法代表真实客户的使用情况。更有效的做法是查看真实客户的查询,与提出查询的用户交流,了解他们的需求,并基于客户数据中的这些实际案例构建评估。这样可以降低评估抽象问题、而非用户真正要完成的工作的风险。Speaker: The sales team found it difficult to create good evaluations at first because internal dogfooding was not representative of real customers. A more useful approach was to inspect real customer queries, speak with the user who made the query, understand what they wanted, and build evaluations around those cases within the customer's data. That reduced the risk of evaluating an abstraction rather than the actual job to be done.
演讲者:对于具有实时记忆的有状态系统,评估会变得更加困难。团队可以评估执行轨迹,例如智能体与记忆交互的效果,但当外部状态不断变化时,离线结果评估就会变得困难。调用第三方服务并随时间改变状态的 MCP 工具也会面临同样的问题。随着 Slack 数据发生变化,基于 Slack 的评估结果可能会漂移,而模拟整个客户环境往往并不现实。Speaker: Evaluation becomes harder for stateful systems with live memory. Teams can evaluate trajectories, such as how well an agent interacts with memory, but offline result evaluations become difficult when external state is changing. The same problem appears with MCP tools that call third-party services and mutate state over time. A Slack-backed evaluation may drift as Slack data changes, while mocking an entire customer environment is often impractical.
发言人:关于模型迁移,建议使用一套严格的评估体系,并避免针对某一模型系列过度优化提示词。新模型可能会带来不同的故障模式,例如不理想的写作风格或生硬的句式。与其追求某一代特定模型的最后一点边际提升(随着模型不断进步,这些提升也会变化),不如识别并防范这些新的故障模式,这样更有价值。Speaker: On model migrations, the advice is to use a strong evaluation suite and avoid over-optimizing prompts for one model family. New models can introduce distinct failure modes, such as undesirable writing patterns or awkward sentence structures. It is more valuable to identify and defend against those new failure modes than to chase the last marginal improvement from a particular model generation, because the latter will change as models improve.
成本、归因与产品控制Cost, attribution, and product control
发言者:对于几乎所有构建智能体的人来说,成本都是一个值得关注的问题。忽视成本的产品很难形成可持续的长期架构。核心问题在于,成本、价值和控制权之间的权衡何时会让团队更倾向于将工作转移到内部完成。参与者认为,托管智能体的基础设施加价幅度相对有限,但也指出了一些限制,例如难以运行某些批处理工作负载。如果一项任务可以提前很久运行,团队或许能通过成本更低、面向批处理的方案大幅节省开支。Speaker: Cost is a concern for nearly everyone building agents. A product that ignores cost is unlikely to have a sustainable long-term structure. The core question is when the cost, value, and control trade-off favors moving work in-house. The participants see the infrastructure markup of Managed Agents as relatively modest, but note limitations such as the difficulty of running some batch workloads. If a job can run well in advance, a team might save substantially through a cheaper batch-oriented approach.
发言人:在短期和中期内,团队可能有更多用户价值需要创造,而不是需要追求成本优化。建议以成熟、审慎的态度管理支出,在托管系统有助于快速学习时继续使用它,之后再优化细节。到那时,托管平台或许已经具备更多优化所需的功能。Speaker: In the short and medium term, teams may have more user value to create than cost optimization to pursue. The recommendation is to be mature and mindful about spending, use the managed system while it enables rapid learning, and optimize details later. By then, the managed platform may offer more of the capabilities needed for that optimization.
发言人:精细化归因同样重要。团队希望了解智能体运行框架中的哪些部分正在累积成本。处理大量数据的大型晚间批处理流程可能会变得很昂贵,但团队通常可以先进行成本较低的工程调整,例如降低运行频率或减少发送的数据量,而不是过早地对整个系统进行过度优化。不过,当规模和成熟度达到一定水平后,他们会希望拥有更强的控制能力和更好的可见性。Speaker: Fine-grained attribution also matters. Teams want to know which parts of an agent harness are accumulating cost. Large evening batch processes that handle significant data can become expensive, but teams can often make inexpensive engineering changes, such as running less often or sending less data, before over-optimizing the entire system. At sufficient scale and maturity, however, they will want greater control and better visibility.
发言者:模型选择是一个重要的成本调节手段。负责协调并执行复杂搜索的智能体可能需要前沿智能水平,但将工作分派给五百个账户,则可能需要成本更低的模型。目前的托管结构可能会让这种优化显得受限,或只能全有全无。参与者希望看到更直观的成本控制选项,包括工作量设置、多智能体控制、更多模型选项,以及灵活模式或批处理模式。Speaker: Model choice is one important cost lever. A coordinating agent that performs difficult search may need frontier intelligence, but fanning work out across five hundred accounts may require cheaper models. The current managed structure can make that optimization feel constrained or all-or-nothing. Participants would welcome more visible cost controls, including effort settings, multi-agent controls, more model options, and flexible or batch modes.
发言人:托管式 Agent 特别适合处理高难度任务:这类任务需要前沿智能,对价格相对不敏感,而且可以运行数分钟,不必将每一秒的延迟都视为关键因素。它们能让团队快速推出这些能力。对于延迟敏感度更高或成本要求更低的工作负载,团队则希望拥有更多调节手段,例如预热沙箱以减少冷启动。最终的观点并不是所有工作负载都应该使用自定义框架。如果必须通过降低成本或加强控制,才能让某项具体功能切实可行,那么多自行构建一些组件是有道理的;否则,团队可以将托管组件与系统中已有的自建部分结合起来。实验的成本往往在于学习所需的时间,而这也是托管解决方案特别有价值的另一种情况。Speaker: Managed Agents work particularly well for hard tasks that need frontier intelligence, are relatively price-insensitive, and can run for minutes without making every second of latency critical. They let teams launch those capabilities quickly. For more latency-sensitive or lower-cost workloads, teams want additional levers, such as pre-warmed sandboxes to reduce cold starts. The final view is not that every workload should use a custom harness. If reducing cost or increasing control is necessary to make a specific feature viable, building more internally makes sense; otherwise, teams can combine managed components with the parts of their systems they already build themselves. The cost of an experiment is often the time it takes to learn, which is another situation where a managed solution can be especially valuable.
