晨启科技

FAQ

What is MCP (Model Context Protocol), and what does it do for enterprise AI deployment?

MCP is an open, vendor-neutral standard for connecting AI agents to external tools and data sources. Its 2026 stateless revision decouples requests from a single server instance's session, removing a long-standing scalability barrier, and adds enterprise features such as header-based routing, cacheable list results, authorization hardening, and a 12-month deprecation guarantee. Now hosted under the Agentic AI Foundation (part of the Linux Foundation), with contributions from OpenAI, Google, Microsoft, and Amazon, MCP turns bespoke, per-system integrations into a reusable, scalable integration layer — exactly what enterprise agents need to move from pilot to production. Read more: https://sixamtech.ai/blog/enterprise-agent-integration-layer-mcp

Should a small business build, buy an agent platform, or hire an FDE to adopt AI?

Decide on two axes: how standard your workflow is, and how much control you need over data, systems, and outcomes. If the work is common and you want to run today, buy a general agent platform (e.g. Nano Work or ChatGPT for small business) — fastest and lowest cost. If your workflow is genuinely unique and you have a stable engineering team, build in-house. If it's complex, needs deep customization, and someone must be accountable for the result, hire a forward-deployed engineer (FDE) to co-build against your real systems. Platforms and FDEs aren't competitors — they answer different questions. Full cost/speed/control/scale comparison: https://sixamtech.ai/blog/enterprise-ai-adoption-path-build-vs-platform-vs-fde

What is AI agent security governance, and how is it different from traditional application security?

AI agent security governance means managing an agent as a new kind of actor — a "non-human identity" that decides, calls across systems, and executes at machine speed — rather than as passive software waiting on a human. Traditional application security assumes a person is behind every session (they log in, get a role-scoped permission, act at human pace). Autonomous agents break those assumptions: their permissions are often over-broad and long-lived, and they can reason about new paths and rebuild tooling when blocked. So the security boundary cannot rely on a model's own restraint — it has to live in the deployment layer: identity, permissions, and isolation. The market already prices this as its own category (in July 2026 Cyera agreed to acquire non-human-identity firm Oasis Security for ~$1B). Full breakdown: https://sixamtech.ai/blog/securing-enterprise-ai-agents-identity-permissions-governance

Why do most enterprise AI projects fail to reach production?

Most enterprise AI projects fail not because the model is weak, but because of three things: the data isn't connected (the model can't reach clean, real-time production data), there's no scenario with clear ROI (AI is adopted for its own sake), and there's no forward-deployed engineering (FDE) — nobody who understands both the technology and the business and owns the outcome. Fixing these three is what moves AI from an impressive demo to real business return. Read more: https://sixamtech.ai/blog/why-enterprise-ai-deployment-is-hard

What percentage of enterprise AI agent pilots reach production in 2026?

Only about 12%. The 2026 State of AI Agents report finds that 88% of enterprise AI agent pilots never reach production — and that failure-to-productionize rate is a different number from the McKinsey finding that 88% of organizations now use AI in at least one function (an adoption rate, not a production rate). Separately, fewer than 10% of organizations have scaled an agent inside a single function and only 39% see measurable financial ROI. The usual blockers are isolation, identity mapping, secrets hygiene, and an audit trail. Full data breakdown: https://sixamtech.ai/blog/enterprise-ai-adoption-2026-reality-check

How do you choose an enterprise agent platform, and what does deployment actually require?

Do not pick an enterprise agent platform on model IQ alone—success in production is decided by six engineering requirements: cost (is token spend on complex tasks bounded), setup barrier (how hard is environment/model/tool integration), permission boundaries (which agents run and which systems they can reach), reliability (has it been validated in real scenarios, not demos), data security (are isolation, permissions, and audit native rather than bolted on), and continuous evolution (who iterates on outcomes after go-live). Evidence: 360 shipped Nano Work only after 1,000+ real scenarios and 166 versions; GitLab 19.2 builds security into the workflow via MCP access control plus AI audit events, and Forrester measured 400% ROI with payback under six months on its agent platform. Ask a vendor these six questions before you commit. Full guide: https://sixamtech.ai/blog/enterprise-agent-platform-deployment-requirements

What is the difference between an AI pilot (PoC) and production-scale deployment?

The core difference is the goal: a pilot (PoC) proves something is technically possible, while production-scale deployment proves it pays off in the business. They differ in data (hand-prepared samples vs live production data), success metrics (demo quality vs ROI and reliability), team roles (mostly data scientists vs adding forward-deployed engineering), and ownership (deliver a demo vs be accountable for the live outcome). Most projects stall by trying to scale while still working like a pilot. Read more: https://sixamtech.ai/blog/why-enterprise-ai-deployment-is-hard

How should enterprises govern AI agent identity and permissions?

Lock down five controls in priority order: (1) short-lived credentials + least privilege — scope every agent's token to one job, expiring by default; (2) sandbox / namespace isolation — run agents in a restricted sandbox and deny privileged workloads by policy; (3) narrow trust boundaries — isolate credentials per agent, never share one key across clusters; (4) block metadata access — cut off default reachability to cloud metadata endpoints and internal services; (5) runtime auditing + cross-system detection — log every call and correlate anomalies across systems. The first three keep an agent from reaching what it shouldn't (cheapest, highest-value); the last two are the containment-and-visibility backstop. The list maps directly to the weaknesses exposed in Hugging Face's July 2026 intrusion post-mortem. Full FDE checklist: https://sixamtech.ai/blog/securing-enterprise-ai-agents-identity-permissions-governance

Why do AI agents work in a demo but fail in production?

Because a demo only tests the happy path while production tests the failure paths. Enterprise AI agents usually fail in production not because the model isn't smart enough, but because four production essentials are missing: a measurable eval set, end-to-end observability, tamper-evident audit trails, and human-in-the-loop guardrails with one-click rollback. Without them, every agent error is a black box you can't catch beforehand, trace afterward, or attribute. Read more: https://sixamtech.ai/blog/why-ai-agents-fail-in-production

What do you need to evaluate before an AI agent goes to production? (agent evals)

Run a fixed eval set as a regression gate before go-live, not a few manual spot-checks. Cover at least three kinds of samples: real tasks (representative cases the agent will actually face), edge cases (empty inputs, long context, missing fields, tool timeouts), and adversarial inputs (privilege escalation, prompt injection, requests it should refuse), each with explicit pass thresholds such as task success rate, unsafe-action refusal rate, and tool-call accuracy. Re-run the suite on every prompt, model, or tool change so "did this change make it worse" becomes a measurable question. Read more: https://sixamtech.ai/blog/why-ai-agents-fail-in-production

Should my company build its own AI agents or keep renting frontier LLM APIs in 2026?

It isn't a binary — it's a curve that moves with scale. Keep renting a frontier API while you're still validating value, running low volume, and carry no hard data-compliance constraint. Switch to owned or custom agents once cost at scale, data sovereignty, or deep customization become bottlenecks — the shift Hugging Face's CEO describes when he notes that scale pushes companies toward open-source models. What decides the outcome is execution, not whether your model is the newest. Full decision framework: https://sixamtech.ai/blog/enterprise-ai-build-vs-buy-2026

Why are AI agents so much more expensive than chatbots?

Because an agent runs a multi-step reasoning loop rather than a single request-and-response. Each step re-sends its accumulated context on the next tool call, so token consumption runs 10–100× higher than a chatbot—and, per LeanOps's 2026 analysis, about 62% of the bill is that re-sent context. The token cost is also only the visible layer: human review, output-quality verification, and downstream maintenance add more. See the full breakdown in [The Hidden Costs of Enterprise AI Agents](/blog/enterprise-ai-agent-hidden-costs-token-governance).

Can enterprise AI be priced on business outcomes?

Yes—wherever the value can be quantified into a measurable, verifiable contract metric. After WAIC 2026, Runjian has run this closed-loop in production ("quantify the economic return of each token, then price on the result"), with seven manufacturing contracts signed and two projects already delivered under its VGE (Value Growth Engineering) model. The practical key is writing outcomes—efficiency gains, cost reduction, or lower waste rates (e.g. Lingchu's ~10% production-waste cut)—into acceptance criteria, and settling on results rather than person-days. Read more: https://sixamtech.ai/blog/enterprise-ai-implementation-ai-fde-closed-loop

How do enterprises control AI agent token costs in production?

Four levers work in combination: prompt caching for stable system prompts and tool definitions, tiered model routing (cheap models for routine steps, a flagship model only for hard reasoning), aggressive context pruning, and hard budget caps. LeanOps reports this combination typically cuts spend 50–70% within two weeks. Uber's enterprise version pairs a $1,500 monthly per-developer cap with a "net code quality ratio" so cost control doesn't erode reliability. Details in [The Hidden Costs of Enterprise AI Agents](/blog/enterprise-ai-agent-hidden-costs-token-governance).

Where is the cost inflection point for self-hosting AI vs. using an API?

The inflection point is an adoption threshold, not a simple 'GPU bill vs. API bill' calculation. Ramp's analysis of 21,000+ U.S. companies found returns showed up only in the top third by per-employee AI spend — about $30 per employee per month in the first three months — and gains compounded only 6–12 months after adoption. Self-hosting saves money only if you can clear that spend threshold and stay past the learning curve; below it, building is usually more expensive, not less. Details: https://sixamtech.ai/blog/enterprise-ai-build-vs-buy-2026

Which large model should an enterprise pick for AI?

Don't start by picking a model. Nvidia's test showed the same frontier model scores 100% with a supervisor-equipped harness and only 30% running bare—what decides success is the engineering shell around the model (harness / runtime / orchestration), not the model itself. The real question is who can engineer the model into a reliable system you can own privately. More in "The Model Is Not the Moat": https://sixamtech.ai/blog/model-not-moat-supervisor-agent-runtime

How is an agent orchestration platform different from just calling the LLM API?

A direct API call is a one-shot, stateless request-response, and a drifting model is unmanaged; an agent orchestration platform adds memory, supervisor-based correction, a persistent runtime (e.g. AWS Bedrock AgentCore sessions run up to 14 days versus 8 hours on a microVM), and multi-agent collaboration on one host. In short: the API gives you the model's intelligence, the platform gives you the system's reliability. More: https://sixamtech.ai/blog/model-not-moat-supervisor-agent-runtime

How do you stop an AI agent from deleting a production database?

Combine two layers. First, least-privilege access, so an agent can only touch what its job requires — this bounds the blast radius. Second, and decisively, a last line of defense the agent itself cannot alter: an immutable, data-layer backup. For example, native WORM (write once, read many) backups — as InfoQ describes with Snowflake's Snowgrid architecture — mean no role or agent can tamper with or erase the safety net, so even a mistaken "delete everything" cannot remove the backup. Prevention (observability + least privilege) lowers the odds; the immutable backup guarantees you can still recover. Full breakdown: https://sixamtech.ai/blog/production-ai-agent-reliability-observability

What is x402 and how do enterprises let AI agents pay on their own?

x402 is an agent-payment protocol built directly on HTTP: it activates the `402 Payment Required` status code (reserved in the spec since 1997) so an AI agent can pay in USDC per request with no account, no API key, and no checkout page — the payment itself is the credential. The handshake is three steps: the agent requests a resource, the server replies `402` with a price, and the agent retries with a payment proof the server verifies. As of July 2026 AWS CloudFront's integration is generally available and Cloudflare's Monetization Gateway opened its waitlist, so the technical layer is largely handled at the edge. See our full guide: https://sixamtech.ai/blog/x402-agent-payments-enterprise-guide

Is agentic (AI agent) payment settlement safe, and how does the money actually move?

The mechanics are more conservative than the idea sounds. Under x402, settlement runs over USDC on the Base chain, clears in under a second, and costs a fraction of a cent per transaction; Coinbase's x402 Facilitator performs on-chain verification and compliance screening before the server accepts payment, so the paying agent is never trusted to self-certify. Payment is also enforced at the edge node — the origin server never receives an unpaid request — which is both a cost control and a security posture. The gap enterprises must still close is not technical settlement but invoicing, VAT, and compliance ownership. Full detail: https://sixamtech.ai/blog/x402-agent-payments-enterprise-guide

Agentic commerce: what must enterprises prepare before enabling x402 payments?

The clouds built the payment pipe but not the accounting: InfoQ reports that invoicing, VAT, and compliance ownership of stablecoin micropayments are unresolved, and neither Cloudflare nor AWS has addressed tax treatment. Before switching on agent payments, map five items to real owners: (1) who issues the invoice of record; (2) which jurisdiction's VAT applies to cross-border micropayments; (3) how USDC settlements are booked in your ledger; (4) who owns AML/KYC review beyond the Facilitator; and (5) who governs and audits the edge payment rules. These are enterprise-integration problems, not protocol problems — and they are what stall a rollout after the tech works. Full checklist: https://sixamtech.ai/blog/x402-agent-payments-enterprise-guide

How do you prove to a customer's security team that your AI agent didn't touch their data?

You prove it with runtime audit — an evidence trail the vendor operates but cannot alter, not a screenshot of your own dashboard. Write every tool call, model call, and data access to a hash-chained, append-only log, so anyone holding a checkpoint can verify the records are untampered (tamper-evident); store raw inputs as a hash plus a redacted summary so the audit trail itself isn't a new leak surface. The open-source Halo library is a reference implementation (~4,300 lines of Python, zero runtime dependencies, with OpenTelemetry / LangChain / MCP adapters). The result: you hand the customer a record they can verify themselves instead of a "trust us." Full guide: https://sixamtech.ai/blog/agent-observability-audit-evaluation-production

What is OpenAI Presence, and why does it ship only through Forward Deployed Engineers instead of self-serve?

OpenAI Presence is an enterprise-grade, real-time agent that works across voice and chat, with early use cases in customer service, outbound sales, and high-stakes internal workflows. It is not sold as a self-serve product: as The Register reported, "Deployments are led by OpenAI Forward Deployed Engineers and select global systems integrators. Presence is not yet available as a self-serve product." The reason is that deploying an agent into high-stakes workflows — grounding it in real systems, handling edge cases, owning accountability — is engineering-and-integration work that cannot be packaged into an API. Full analysis: https://sixamtech.ai/blog/openai-presence-fde-enterprise-ai-delivery

Why does enterprise AI deployment need forward-deployed (FDE) delivery instead of a self-serve API?

Because "we bought a model" is nowhere near "we deployed it." As models commoditize, differentiation and margin move to the "plumbing" — integration, deployment, and orchestration — which cannot be shipped as an API. The signal: even OpenAI won't let enterprises stand up Presence on their own, deploying it only via Forward Deployed Engineers. The failure data agrees — Gartner has predicted that by 2027 half of the organizations planning to shift customer service to AI will abandon those plans (as reported by The Register). Forward-deployed delivery closes that gap by embedding outcome-aligned engineers who turn a demo into something that runs in production. More: https://sixamtech.ai/blog/openai-presence-fde-enterprise-ai-delivery

Which AI agent observability and evaluation platforms exist, and how do you choose?

Start from the job you need done, not "which is best." Three mainstream open-source platforms specialize differently: MLflow (~27k stars) is an engineering platform pairing tracing with evaluation; promptfoo (~23k stars) focuses on evaluation plus adversarial red-teaming; opik (~20k stars) centers on runtime monitoring of agentic workflows. Those three serve your own team's confidence; to prove to a third party — a customer's security team or compliance — what actually happened, add a separate tamper-evident audit layer such as Halo. It is orthogonal to the other three, and your own monitoring dashboard will not clear a security review. (Star counts are a 2026-07 snapshot.) Full guide: https://sixamtech.ai/blog/agent-observability-audit-evaluation-production

What is an AI FDE (Forward Deployed Engineer)?

An AI FDE (Forward Deployed Engineer) is a delivery model in which engineers are embedded inside the customer's operations — bringing their own tooling and compute — to co-discover AI use cases, deliver measurable results, and get paid on outcomes rather than on hours, licenses, or slides. The difference from ordinary on-site staffing is that a traditional deployment bills person-days while an AI FDE bills verifiable business results. Runjian localizes the role as VGE (Value Growth Engineering) and reports seven signed manufacturing projects, two already delivered. Read more: "What Is an AI FDE? From Selling Models and Tokens to On-Site Delivery and Value-Based Pricing" https://sixamtech.ai/blog/what-is-ai-fde-value-based-delivery

How is an AI FDE different from IT outsourcing and consulting?

The core difference is what gets delivered, who owns deployment risk, and how it is priced. IT outsourcing hands over software licenses and person-days, and consulting hands over a slide deck — both leave deployment risk with the customer. An AI FDE delivers running agents embedded in the customer's systems plus measurable business outcomes, stays on-site to co-own the risk, and prices on value delivered (quantifying the economic gain per token into a closed value loop). The test for a real FDE: is the vendor accountable only for shipping a system, or for the business result? See the full comparison table: "What Is an AI FDE? From Selling Models and Tokens to On-Site Delivery and Value-Based Pricing" https://sixamtech.ai/blog/what-is-ai-fde-value-based-delivery

Do small and mid-sized businesses need embedded (on-site) AI deployment, or is a self-serve API enough?

Yes. The hard part of getting AI agents into production is organizational — adapting cost, permissions, stability, and security to how the business actually runs — not the model itself. Smaller teams have less slack to absorb a failed self-serve rollout and less tolerance for an agent that takes a wrong action, so a guided, embedded approach that starts from one concrete use case tends to pay off faster than a self-serve API. It is the same logic behind OpenAI delivering its Presence product through forward deployed engineers rather than a self-serve API. More: https://sixamtech.ai/blog/openai-presence-forward-deployed-engineers

What's the risk of betting your enterprise AI on a single model provider?

The biggest risk isn't price—it's outsourcing your judgment and losing control. Microsoft CEO Satya Nadella put it bluntly: a firm without this control has essentially outsourced its thinking. Three practical hedges: (1) retain the full metadata from every model call, so you can later fine-tune your own weights or move to open models; (2) put an AI gateway between your prompts and any single model to decouple them; and (3) don't lean on one lab's built-in coding harness as your only path. All of this is easier when your implementation partner stays cross-model neutral and has no incentive to route you into one ecosystem—which is the core difference between an independent, value-based partner and an AI lab's own delivery team. See [Enterprise AI agent deployment: AI lab vs in-house vs independent partner](/blog/enterprise-ai-agent-deployment-fde-vs-build-vs-partner).

公司动态