编码智能初学者小组实验室

Xcode engineers introduce themselves and frame a beginner-oriented session on Coding Intelligence in Xcode 27 — the agentic coding experience, chat versus agent modes, connecting cloud and local models, the Agent Client Protocol (ACP), permissions and privacy, and how to learn agent-driven workflows.

Type "/" in the agent to see the commands the agent reports it supports plus any skills Xcode has loaded. You can also just ask the agent — it's aware of nearly every command and what each does. Experiment with both and try commands to discover the workflows Xcode and the agent provide.

The panel doesn't discuss future plans, but pointed to Xcode's advantages today: a carefully designed tool set and curated knowledge about Apple platforms and APIs given to the agent, combined with a native UI purpose-built for coding rather than a general-purpose terminal agent.

Xcode's UI doesn't directly surface how much agentic resource a request is consuming — instead, ask the agent, since your provider exposes a slash command for it. There are usually two separate numbers: how full the coordinating agent's primary context window is, and how much you've spent or used so far; it's easy to confuse the two. If you'd like this surfaced in the UI, file a feedback request.

This is governed by Xcode's agent security modes. By default the agent uses permission prompting — it can reach what it needs but not roam freely. You can adjust the permissions and working directories the agent is allowed to access, so you can grant access to another local project when cross-project references are needed.

You can already get this by asking the agent — request an explanation in whatever form you like (a Markdown file, an HTML report, or "help me understand why you did this"). You can also configure recurring behavior via an AGENTS.md in your project so the agent explains its work by default, turning each session into a learning opportunity.

Agents commit whole classes of bugs, like humans. The subtlest is not sharing your unstated assumptions — you may get something different from what you meant, or an unmaintainable version of what you asked for. They can also miss context. Review the output critically rather than assuming working code is correct code.

Two paths already exist. You can tell the agent "this doesn't work, go back to the previous state" and it rolls back using its full context. Xcode also tracks state across each agent turn when your project has an initialized git repository, so you can open that history and revert to a prior turn.

Start small and fold it into work you're already doing — small changes or minor bug fixes you'd rather not spend time on — so you can review the results closely and build intuition. You don't need a massive project to begin; incremental, everyday use is the fastest way to develop the skills.

The difference is capability. Chat mode gives the model only a small, fixed tool set — on the order of 10 to 15 things it can do to your codebase — whereas agent mode (surfaced at the top of the UI) gives it command-line tools plus nearly 60 tools inside Xcode, along with the agent wrapper that manages context and can spawn sub-agents. That's why a local model in chat mode behaves very differently from the Coding Intelligence demos, and why the recommendation is to move from chat to agents.

Separate the agent from the model it talks to — you can mix and match. Xcode has supported local models (on your machine or a local server) from the start. Using a local model in chat mode gives you the chat experience; local models are getting very capable, and to get full agentic behavior you connect them through the agent path rather than plain chat.

Yes — use ACP (Agent Client Protocol), which is the intended path. Many open-source tools and wrappers with local-model support (such as OpenCode) work this way, and ACP lets enterprises bring their own configuration and back-end harness into Xcode while keeping the more capable agent behavior.

When you enable a coding agent and model from a partner, you see that provider's terms for how they use your code, and you're always in control of whether to allow them to use your code for training. You manage this in your account settings with the provider, so the data-use and training choices are explicit and yours to make.

MLX is the best way to run a capable model locally — you can run a larger, more interesting model with MLX than with any other technology on Apple devices, and there's a dedicated session on using it in this context. Combine that with agent guardrails to make offline, local work practical on more modest hardware.

Everyone approaches agents differently, and that's fine. What Xcode adds is powerful platform-aware tools plus a purpose-built user experience — including support for non-linear flows — layered on top of the raw agent, rather than the linear back-and-forth of a terminal harness. The value is in that integrated, native experience.

Yes — the "Run local agentic AI on the Mac using MLX" session is the best starting point. To balance speed, accuracy, and privacy, consider a hybrid: use a larger model for planning, then have a smaller local model carry out and track the work and its assumptions.

Yes — run local, agentic AI on the Mac with MLX rather than a third-party cloud provider. The Mac is a strong platform for this: even a single high-end Mac is capable, and an array of Mac Studios could host among the largest models, keeping everything on your own hardware.

For a conceptual roadmap rather than jump-in tutorials, the "Xcode agents" (Meet the coding agent) WWDC session is a good fit — especially for visual learners, since it includes illustrative diagrams of what the agent is actually doing, giving you the overall map to fill in with details later.