AI 服務暫時不可用，以下為來源正文，待恢復後補全翻譯。
Building a working agentic prototype takes an afternoon. Getting it to production is where the work explodes. The moment an agent has to serve more than one user, a new layer of engineering appears and it’s critical to tell whether the agent is doing the right thing on real traffic. Concurrency, session isolation, identity, persistent state, scaling, and guardrails are all layers that most teams rebuild from scratch every time, even though a standardized platform for each agent is a more repeatable approach. The result is a wide gap between experimentation and production. Industry surveys through early 2026 put enterprise AI experimentation near universal while only about a quarter of organizations have scaled agents into production in even one function. Internally at Wood Mackenzie, we have found that 88 percent of AI proofs-of-concept never reach widescale deployment. The reasons are consistent across analysts, and they are mostly architectural rather than model-related. Forrester attributes agent failures largely to ambiguity, miscoordination, and unpredictable system behavior rather than ordinary bugs. The most-named single blocker is evaluation and observability: teams cannot reliably tell ahead of time when a non-deterministic agent will be wrong, and standard regression tests do not catch it. Governance and identity follow close behind, with a large share of executives reporting they could not immediately shut down a misbehaving agent. Underneath all of it is duplicated infrastructure: each team re-implements authentication, guardrails, memory, and tracing, and hardcodes a model so that swapping providers means rewriting code. This is the problem a shared agentic platform solves. Instead of every team rebuilding the same foundation, one runtime handles orchestration, safety, observability, identity, and connectivity, and teams spend their effort on the business logic that differentiates their product. In this post we show how we built APEX (Agentic Platform for Energy eXperience), a shared platform so every team can ship agents without reinventing infrastructure. APEX is built on Amazon Bedrock AgentCore, a platform to build, connect, and optimize agents at scale, with any framework or model. We cover why we selected AgentCore over self-hosted solutions, how the architecture is composed, how APEX Studio gives teams a single control plane to operate it, how we bring interactive AI into real applications for both internal users like Woody and external consumers like Lens. We will also dive into how the same infrastructure serves both under identity-aware entitlements, how we close the evaluation and governance gaps that stall most agent programs, and where the platform is heading as multi-agent systems become the default. Why a shared platform, and why AgentCore Before APEX, three applications were each on their way to building their own agent stack: Woody, Lens AI, and the ST Trading App. Left alone, each would have stood up its own runtime, wired its own identity, bolted on its own observability, and hardcoded its own model. We would have paid the same infrastructure tax three times and ended up with three stacks that could not share memory, tools, or evaluation. AgentCore resolves this problem by providing a platform capable of meeting the needs of an enterprise scale agentic deployment. We evaluated AgentCore against the requirements of a production platform: hosting model, cost model, whether it is model agnostic, scalability, governance, and enterprise support. Framework Hosting Cost Model Model Agnostic Scalability Governance Enterprise Support LangChain Self-Hosted Free/Enterprise Yes Manual DIY Community LangChain Self-Hosted/ LangSmith Free + LangSmith Yes Manual LangSmith Community CrewAI Self-Hosted/ CrewAI-Cloud Free/ Cloud Yes Limited Basic Community n8n Self-Hosted/ Cloud Free/ Pro No Moderate Workflow Community + Pro Frontier Model Direct Provider-hosted Per-token No Provider-Managed None Provider SLA Bedrock AgentCore AWS managed Pay-per-use Yes Automatic scaling Native Amazon Bedrock Guardrails and Policy AWS Enterprise SLA AgentCore provides us a managed platform rather than a library we would need to operate ourselves. It works with any open source framework, including Strands Agents, LangGraph, LangChain, LlamaIndex, CrewAI, Google ADK, OpenAI Agents SDK, and with any model whether or not it runs on Amazon Bedrock. It supports both the Model Context Protocol (MCP) and the Agent-to-Agent (A2A) protocol. That meant we didn’t need to choose between open source flexibility and AWS service security. This allowed us to standardize the platform layer while leaving each team free to pick its own framework and model. Five capabilities decided it for us: Managed infrastructure. There’s no cluster to operate. AWS handles scaling, patching, and availability, so our platform team focuses on agent capabilities instead of backend plumbing. AgentCore reached general availability (GA) in October 2025, and at GA all services added support for Amazon Virtual Private Cloud (VPC), AWS PrivateLink, AWS CloudFormation, and resource tagging. True model agnosticism. Claude, GPT-4.1, Amazon Nova, Mistral, and Llama are all reachable through a single platform. A team can plan with one model and execute with another, run a price-performance test by swapping providers, or move off a model that shipped a regression, without losing conversation context and without touching business logic. Automatic scaling. AgentCore runtime, a capability of Amazon Bedrock AgentCore, goes from zero to thousands of concurrent agent invocations with no capacity planning, with complete session isolation and execution windows up to 8 hours. Native guardrails and identity. Content filtering, personally identifiable information (PII) detection, and policy enforcement are managed capabilities rather than something each team reimplements. Policy in Amazon Bedrock AgentCore integrates with the Gateway to intercept every tool call in real time and converts natural-language rules into Cedar, the AWS open source policy language, so development, compliance, and security teams can author and audit rules without custom code. AgentCore Identity, a capability of Amazon Bedrock AgentCore, adds AWS Identity and Access Management (IAM) integration, VPC isolation, and encryption, so agents support your compliance requirements and can act on behalf of a user or on their own under defined access controls. AWS Enterprise Support. AWS Enterprise Support provides 24/7 support as well as a technical account manager (TAM) and account team relationship that helps customers influence the roadmap for products like AgentCore based on our needs. AgentCore uses consumption-based pricing with no upfront commitments or minimum fees. Each service is billed independently, so a team can adopt a single capability such as AgentCore memory, a capability of Amazon Bedrock AgentCore, without migrating its entire agent. Runtime billing is based on active CPU and memory consumption calculated per second, and CPU charges don’t accrue during I/O wait. This matters for agentic workloads, which typically spend 30–70 percent of their time waiting on model responses, tool calls, or database queries. With pre-allocated compute you would pay for that idle time. With AgentCore, you do not. Solution overview APEX is organized in layers, shown in Figure 1. At the top, end users interact with three applications: Woody, Lens AI, and the ST Trading App. Those applications talk to the APEX frontend, which exposes a framework so product teams can drop agentic capabilities into a user interface without rebuilding the connection to the backend each time. The APEX backend is where AgentCore does the work. Two infrastructure tracks sit alongside the backend. The WM infrastructure as code (IaC) Framework uses the AWS Cloud Development Kit (AWS CDK) and GitHub to provision and version platform resources, with guardrails defined in code. The MCP layer connects the platform to third-party and external access, including AWS Marketplace and partner systems, over a standard protocol rather than bespoke integrations. Users reach three applications through the APEX frontend SDK. The APEX backend runs on AgentCore (Runtime, Identity, Gateway, Memory, Observability) with an Orchestrator, a vector database for retrieval, model access through the Amazon Bedrock model catalog, and Amazon Bedrock Guardrails. The WM IaC Framework provisions resources through AWS CDK and GitHub, and the MCP layer connects external systems. Figure 1: APEX reference architecture Inside the backend, a request flows through these components. User Authentication and AgentCore Identity establish who is calling and what they are entitled to do. Identity and entitlements are woven into every agent invocation rather than checked once at the edge, so an agent acting on a user’s behalf carries that user’s permissions through every downstream tool and data call. Federation to your identity provider of choice is also important. We use Okta as our source of truth. The Orchestrator routes the request and consults the Woodmac Agent Registry, a single place to discover, share, and reuse agents, tools, and skills across the organization with built-in governance and approval workflows. This is how one team’s agent becomes available to another without copying code. AgentCore runtime hosts the agent code in a serverless, session-isolated environment. Inside the runtime we run AI Agents Studio (built on Amazon Quick with Strands Agents, LangGraph, CrewAI, n8n, Vertex, and OpenAI), so each team keeps its preferred framework. The runtime invokes models through the Amazon Bedrock model catalog, which is where model agnosticism becomes concrete: the agent points at a model by name and we swap providers without rewriting the agent. Tools are exposed to the agent as composable building blocks. The architecture shows how Wood Mackenzie uses a Code Interpreter tool for secure code execution and an Amazon Nova Act web tool for browser actions. These tools are reached through AgentCore Gateway, a capability of Amazon Bedrock AgentCore, which turns APIs, AWS Lambda functions, and existing MCP servers into agent-compatible tools and provides a single secure endpoint for discovery and invocation. The Gateway pulls from a Tools Repository for discovery and invocation, and supports IAM, OAuth 2.1, and API key authentication. Retrieval Augmented Generation (RAG) over a vector database grounds the agent in our own content, including unstructured documents, so responses are based on retrieved facts rather than the model’s parametric memory alone. We use Amazon Bedrock Knowledge Bases as a serverless and managed way to provide RAG to our agents. AgentCore memory gives the agent short-term and long-term context, so a conversation persists across sessions and agents can share state instead of each maintaining its own store. Amazon Bedrock Guardrails and Policy govern allowed prompts and intercept tool calls, enforcing content filtering, PII detection, and the Cedar-based rules described earlier. Observability and evaluation determine whether an agent survives in production. Agent output is non-deterministic, so the hard question isn’t does it work but can we tell when it stops working. AgentCore Observability, a capability of Amazon Bedrock AgentCore, emits telemetry in OpenTelemetry-compatible format to Amazon CloudWatch, covering session count, latency, duration, token usage, and error rates. Wood Mackenzie can then trace a single request from a session down to an individual span, with logs from each component surfaced at the right step instead of scattered across log groups. On top of that, AgentCore Evaluations, a capability of Amazon Bedrock AgentCore, gives us built-in evaluators for quality dimensions such as helpfulness, tool selection, and accuracy, plus c [truncated for AI cost control]