The subject of how to price an agile contract is both too opinion-based and too broad for a single generic answer. However, a number of books touch on the topic, and there are certainly plenty of starting points to form your own process. I list some external references below, and include some of my own experiences and recommendations as well.
Some External References
Some places you might start researching the current body of thought on this issue include:
A little searching will yield many more documents, articles, and blog entry results.
Some Distilled Thoughts
Some Types of Agile Contracts
Having been doing Scrum contracting for a long time, I have my own empirically-refined opinions on the subject. In general, if you accept axiomatically that agile frameworks trade fixed scope for incremental delivery and project visibility, then you can structure your agile contracts in a couple of ways:
In Scrum, you should be producing a shippable increment at the end of each Sprint. As a result, contracts based on a per-sprint or shippable increment basis are a great substitute for fixed-price contracts.
Time and Materials
Agile frameworks like Scrum provide customers and stakeholders regular inspect-and-adapt inflection points such as Sprint Planning and the Sprint Review. This allows contracts to be based on time and materials, but remain flexible on scope throughout the lifetime of the project. The client can then declare victory whenever the project has delivered sufficient value, or cancel the project whenever the costs exceed the expected return.
Yet another option is fixed time and flexible scope. For example, a client may present a backlog that the team estimates at 26 sprints. The contract can specify a fixed number of sprints, and then the client and team work together to maximize the value delivered within the agreed-upon number of iterations.
I tend to prefer time-and-materials or fixed iterations in my own contracts, but your mileage may certainly vary. There are certainly other ways to structure such contracts; you need to find out what works best for your organization.
Hard Requirements for Agile Contracts
In my opinion, the only truly fixed requirements of an agile contract are that the contract must:
Agile projects are still constrained by the iron triangle. You cannot contractually constrain a project in all dimensions (e.g. time, scope, and cost) simultaneously and still expect success. Because agility is about embracing change, I personally recommend leaving scope as the unfixed dimension.
It's certainly possible that there are edge cases where it's best to fix scope and unconstrain one of the other dimensions, but in my own practice that has rarely been the best choice when following Scrum. Your personal experience might differ.